machine placement spec
william.reade at canonical.com
Fri Nov 11 11:20:53 UTC 2011
On Thu, 2011-11-10 at 16:14 -0200, Gustavo Niemeyer wrote:
> If the command does something entirely different, with different
> semantics, different arguments, and needs a different help text, is it
> the same command?
> Maybe set is a good target for some of the functionality, but what
> part it is, and why? The reasoning should be better than "less
Very sensible, I think I just mentally archived a past conversation as
"minimize verbs" :).
> > The idea was:
> > juju deploy foo -c ram=512M -c "orchestra-classes=blib blob blub"
> > Bad idea, or just badly expressed?
> Bad idea. We should be able to express multiple constraints next to
> each other for several reasons (think charms and stacks).
Expand please? If we're expressing them in stacks or charms I think I'd
rather have a yaml list of distinct constraints than to smush them all
together and have to parse them out myself, and to my eye it's quite
convenient and readable to have a separate command-line option for each
> > I don't think we *need* to understand floats, but I think I'd rather
> > type "2.5T" than "2560G". I think the slightly greater ease for users
> > outweighs the minimal -- if any -- additional effort in parsing.
> Sounds good.
> > The region is an environment-level setting because it already is.
> > Assuming rearrangement of environment config, I imagine it won't be, so
> > this can change. ec2-zone was never intended to be environment-level.
> I meant to say why is this _only_ an environment setting. This seems
> equivalent to every other setting in that regard.
Yep, I hadn't really considered the consequences of fixing the
> > by orchestra-classes *plus* asking the admins to add a bunch of
> > single-machine classes named after their systems. I understand that we
> > may prefer that admins not think about individual machines; but they 
> Any constraint that can only ever resolve to an individual machine
> kills several other features of juju on the way. Given that it's
> trivial to have classes that individually identify a machine, and that
> naming a machine specially or adding an individual class specially is
> an equivalent effort, and also that we need class handling anyway and
> that it's extra work to handle names, I'd still prefer to put that
Hmm, given that we're cut unit constraints for now, this restriction
makes a bit more sense (it's clearly inappropriate to specify
orchestra-name for a service, because that will actively prevent you
from deploying more than one unit -- unless you hack around it by
resetting constraints every time you deploy). Caveats remain, though:
1) I don't see a significant distinction between a constraint that
*might* translate to a single machine and a constraint that *always*
translates to a single machine. Either is well defined, and either could
fail, just like any other constraint.
2) The effort is not equivalent: cobbler machines always have names
already, but for every machine admins would have to (i) create a new
mgmt-class and (ii) actually set it on the machine.
3) Using mgmt-classes would therefore be frustrating and
human-error-prone; but I strongly suspect they'd still do it, and
pollute mgmt-classes to do so, and furthermore would end up setting it
on the service and changing it for every deployment. This may even end
up being the killer argument for unit constraints as well; it's a use
case we *know* exists, and from a user perspective the difference
* juju deploy nova-compute -c orchestra-name=cyclopean-iron
* juju add-unit nova-compute -c orchestra-name=gargantuan-iron
* [create mgmt-class "cyclopean-iron"]
* [set "cyclopean-iron" mgmt-class on system named "cyclopean-iron"]
* [create mgmt-class "gargantuan-iron"]
* [set "gargantuan-iron" mgmt-class on system named "gargantuan-iron"]
* juju deploy nova-compute -c orchestra-classes=cyclopean-iron
* juju set nova-compute -c orchestra-classes=gargantuan-iron
* juju add-unit nova-compute
...is pretty significant.
However, at least we will provide a mechanism, and on balance I'm
prepared to defer (if not drop) my support for this feature, at least
until we come to consider unit constraints.
> > It was originally because they ignore all parent constraints, but yes:
> > since I decided there was no reason not to let them use additional
> > constraints at the same level it doesn't fit so well. I'll try to come
> > up with a better name.
> > True. I'm reluctant, because I think a lot of people consider it to be
> > an important feature, but I'm at more reluctant to put unbound units
> > together without some sort of isolation.
> It is an important feature for sure. Keeping it out of the spec
> doesn't mean it's less important, but rather that it doesn't impact
> the basic work that has to take place in any significant way, and that
> we haven't agreed to the details right now nor do we have to for the
> > Yep, we can completely lose all the specified override constraints
> > without affecting anything else. I'm a little concerned that this kills
> > a use case that comes up quite frequently, but... yeah, unit
> > isolation :( .
> Again, it doesn't _kill_ a use case. Having a partially and
> hard-to-agree feature in a spec that has a tons of dependencies
> specified already won't get the feature done any faster.
Agreed, forgive the whinging ;).
> > My understanding is that the orchestra team would prefer to expose a
> > distinct API rather than add this to cobbler, but I defer to someone who
> > knows for sure how they'd like to do it. Anyone? :)
> I'm not sure I understand what you mean in this case. Orchestra ==
> Cobbler to a large degree.
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
> > So, something like "juju set-constraints", which can affect either
> > environment or service?
> Potentially. Or maybe putting part on "juju set" (the service bit) and
> part on a set-env command that also handles other environment aspects.
> Have we reached agreement on how to tweak other environment settings
Yeah, plausible; I'll think about it. I'm not sure whether we reached
consensus about how to restructure environment settings yet; that is
definitely a prerequisite for this feature.
> > Cool, I'd be happy to lose the capability myself. Do we know if anyone's
> > currently depending on it?
> Just recently someone mentioned it doesn't even work.
Cool (for a given value of cool).
> > That's only going to be the case if he specifies "cpu=max" *and*
> > "ram=max"; in which case he's quite explicitly saying that he wants a
> > machine with at least as much of both RAM and CPU as any other he has
> > access to. It's no different to failing because you specified, say,
> > "ram=38T": juju can't give you what you asked for, so it fails.
> Exactly. I understand the scenario.. my point was just that it's an
> unlikely requirement for someone to ever want.
> > So: I'd expect people to generally use one "max" at once, but I thought
> > it was important to specify how multiple max~s would have to interact.
> Part of the point is that they seem to interact badly.
A number of constraints can interact badly: "ram=64G" and
"ec2-instance-type=m1.small", for example, cannot both be satisfied. IMO
the deciding factor should be "is `max` actually useful?" rather than
"does `max` allow people people to express unlikely requirements?".
> > Everything in this document is either something we discussed in the
> > design sessions, or that at least one person at UDS mentioned
> > wanting/needing. We don't have to include them, but we should still
> > consider them.
> Agreed.. that's what we're doing thanks to your awesome coverage.
> History here is settled as well, so we can always come back to
> reevaluate these ideas.
Excellent; expect a new draft with the settled points imminently.
More information about the Juju