Add generic and tag constraints to maas provider

Add generic and tag constraints to maas provider

Passes through standard constraints 'arch', 'cpu', and 'mem', also
specific 'maas-tags' which can be used to indicate other properties.

Launching a new machine still involves calling acquire in the MaaS api
which returns only one node rather than a list of candidates to select
from, so the constraints are still not used on the Juju side for now.

https://code.launchpad.net/~gz/juju/add_maas_constraints/+merge/126203

(do not edit description out of merge proposal)

[gz, 2012-09-25 09:18:13]

Please take a look.

[hazmat, 2012-09-27 04:54:45]

from irc

Sep 25 05:27:05 <jam>   mgz: well I know hazmat asked us to make it less
specific, so the provider should query Maas for a list of acceptable tags.      
                                       
Sep 25 05:27:10 <mgz>   could just pick nodes with a superset of the tags
specified, or could do full boolean logic                                       
                                      
Sep 25 05:27:18 <jam>   less generic?                                           
                                                                                
                               
Sep 25 05:27:44 <mgz>   I think hazmat will be fine with maas returning good
errors for non-existant tags or a bad tag string                                
                                   
Sep 25 05:27:49 <jam>   The argument is that deploying is async, so by the time
the provider responds, it is too late to inform the user of a typo/etc.         
                                
Sep 25 05:28:35 <mgz>   right, so provided we catch before acquire actually
happens that a tag is bad, and return a 4XX straight away without going down to
the cluster, I think that's fine     
Sep 25 05:30:49 <mgz>   ...I probably want to add some tests for that error case
                                                                                
                               


so a user on the cli is going to do something like

  juju deploy xyz --constraints="maas-tags=foo&bar"

except bar doesn't exist, and they'll never see an error, just an instance which
stays forever in pending state, and errors in the provisioning agent log.

given that this is effectively free form vocabulary of values, it would be nice
to see a validation of the constraint value to prevent this.

constraint validation facilities are a bit weak but effectively on
register('maas-tags') you can just pass the a converter function with the
vocabulary introspected from the maas server. the logical operators can be
stripped and the remainder differenced against the vocabulary to detect unknown
values, raising a constrainterror on invalid values.

https://codereview.appspot.com/6569053/diff/1/juju/providers/maas/maas.py
File juju/providers/maas/maas.py (right):

https://codereview.appspot.com/6569053/diff/1/juju/providers/maas/maas.py#new...
juju/providers/maas/maas.py:48: ("maas-name", "name"),
is maas-name still supported?

[gz, 2012-09-28 11:34:38]

Please take a look.

[hazmat, 2012-10-01 14:39:59]

looks nice, thanks.

One concern for which i'd request you'd file a new bug for future ref, is that
given the valid tag set could change at any time, a previously valid set could
become invalid. That's deferrable for now, at the moment it will just yield a
problem creating services.

[gz, 2012-10-01 17:35:39]

On 2012/10/01 14:39:59, hazmat wrote:
> looks nice, thanks.
> 
> One concern for which i'd request you'd file a new bug for future ref, is that
> given the valid tag set could change at any time, a previously valid set could
> become invalid. That's deferrable for now, at the moment it will just yield a
> problem creating services.

I've filed bug 1059753 which I hope captures this issue, feel free to edit the
summary if I have any terminology or details confused. Thanks!