machine placement spec
william.reade at canonical.com
Fri Nov 11 14:47:25 UTC 2011
On Fri, 2011-11-11 at 11:10 -0200, Gustavo Niemeyer wrote:
> Parsing the format is trivial:
I guess :). OK, convinced. Comma-separated list for orchestra-classes.
> > resetting constraints every time you deploy). Caveats remain, though:
> > 1) I don't see a significant distinction between a constraint that
> > 2) The effort is not equivalent: cobbler machines always have names
> > 3) Using mgmt-classes would therefore be frustrating and
> You make good points. +1 on the option.
> > "Sharing constraints"?
> Co-location constraints? :-)
> I'd vote for using the term co-location to refer to the concept of
> co-location generically (slave or not). That's how people hear it
> > Not really -- it's just one of the parts of orchestra that we interact
> > with (the other is the webdav storage). My understanding is that it may
> > be simpler/cleaner for them to expose the information without modifying
> > cobbler, but I'd have to defer to someone who knew the details to
> > explain why.
> I imagined they'd just stick the extra metadata into an existing field.
Chatted to zul; it seems it's pretty easy to add new fields to cobbler,
which IMO is much better than polluting existing ones.
> > A number of constraints can interact badly: "ram=64G" and
> > "ec2-instance-type=m1.small", for example, cannot both be satisfied. IMO
> This doesn't have to be a conflict. I'd pick ec2-instance-type if
> running on EC2 since it's most specific, and drop ram. In other
> providers, I'd keep ram. This is much more useful then breaking down
> if the user selects both.
Hmm, yes, but it feels unpleasantly complex to have to keep track of
which provider constraints can shadow which generic constraints (and far
too easy to get inconsistent behaviour -- OK, setting orchestra-name
should probably imply `ram=0 cpu=0`, but certain orchestra-classes could
well embody such constraints -- except there's no way for us to know
about them, so we can't treat them in the same way).
And what about the possibility of overlapping provider constraints? I
feel that as we add more constraints, the questions of what should
override what else will become thorny; it seems much cleaner to make all
constraints independent and required, and make sure we have sensible
error messages so it's easy for people to stick `ram=0 cpu=0` on the
end, for example, to ignore the constraints they don't want.
> > the deciding factor should be "is `max` actually useful?" rather than
> > "does `max` allow people people to express unlikely requirements?".
> Ok, it's a valid suggestion either way.
And it's in the enhancements section anyway :).
More information about the Juju