machine placement spec
william.reade at canonical.com
Mon Nov 21 10:16:14 UTC 2011
On Thu, 2011-11-17 at 01:53 -0200, Gustavo Niemeyer wrote:
> > ...and here's the latest version, incorporating the recent discussions
> > (I think; let me know if I've missed anything).
> Great stuff. I'll highlight just a few last points, but overall we're
> almost ready.
Thanks -- couple of points, I'll do a final spec when we have agreement.
> Let's take this as an example:
> juju set --constraint ec2-type=small postgres username=joe
> It just doesn't feel correct to have both of these in the same
> namespace. The configuration options are entirely unrelated to the
> As a solution to avoid this, I suggest we create a new command called
> set-constraints that handles that, specifically, with a syntax like
> juju set-constraints ec2-type=m1.small ec2-zone=eu-west-1
> The above changes the default for the environment. For changing a
> specific service, the following would be used:
> juju set-constraints --service=postgres ec2-type=m1.large
> And perhaps at some point:
> juju set-constraints --unit=postgres/0 ec2-type=m1.large
> How does that feel?
Fine, expect I think we can eschew the explicit "--service=" without
ambiguity; we can just:
juju set-constraints ec2-type=m1.small
juju set-constraints postgres ec2-type=m1.large
I don't think set-constraints is meaningful for a unit; if the unit
exists, it's past having its constraints modified.
> > We also extend the syntax for `juju deploy`, such that `--constraints`
> > is understood as above; these constraints will be set on the service
> > before the first unit is deployed.
> +1 on that.
...and, if we do do units, the right time to set the constraints is
add-unit time, which would also have its syntax extended.
> Let's please call it "mem" as we've been discussing since that's how
> most people relate to this concept, including the well known
> > * `ec2-zone`: availability zone within the region. Defaults to "a";
> > valid values depend on the current value of `ec2-region`.
> It should default to unset, allowing the use of any zone. Considering
> that Amazon shuffles zone names either way, we can't really use that
> > Note that provider constraints can overlap with generic constraints:
> > it would not be possible to deploy a machine with the constraints
> > `ram=8G` and `ec2-instance-type=m1.small`, because the requirements are
> > contradictory.
> This feels like a bad idea. We said we'd be ignoring provider-specific
> constraints so the charms are portable to different providers. When
> that's the case, the generic constraints will be useful, so it sounds
> very reasonable to say that the most specific constraints take
I'm not quite sure about this myself; provider-specific constraints
"feel" as if they should override whatever specific ones exist, at least
in some cases... but I can't come up with a use case that isn't
counterbalanced by another that prefers your way, so I'm happy to go
with it unless someone else chimes in with a compelling argument.
> > Finally, please note that for the local LXC provider, given its nature
> > and its intended use as a development tool, no constraints have any
> > effect whatsoever.
> s/local LXC/local/.. it's really about local rather than LXC.
> > Issues
> > ------
> > Please note that this spec depends on features of juju and orchestra
> > that are not present at the time of writing:
> > * We need orchestra to expose `cpu` and `ram`; as long as the numbers
> > are available, the orchestra team is free to expose them in whatever way
> > is convenient; but the feature will be severaly hobbled if we don't have
> > access at all.
> > * Environment settings will need to be rearranged, and our handling of
> > `environments.yaml` will need to change, so that we can separate an
> > environment's access information from the runtime properties contolled
> > by `juju env-set`.
> > Potential Enhancements
> > ----------------------
> > The above spec is intended to be small and focused; several enhancements
> > are possible and may be desirable in the future. They include:
> > * Unit-level constraints, specified at `juju add-unit` time, and
> > inheriting naturally from service, environment, and juju.
> > * An additional generic constraint, `storage`: The minimum persistent
> > disk space for the machine, defaulting to 4GB. Valid inputs as for
> > `ram`.
> > * Max constraints: allow generic constraints to also take the value
> > `max`, meaning "the best available". (If you specify both `cpu=max` and
> > `ram=max`, the constraints cannot be satisfied unless there is an
> > available machine with the (equal) greatest amount of RAM and also the
> > (equal) most processing power; in general, we would expect people to
> > only set one constraint to `max`.)
> Please capture also the concerns exposes during discussion about the
> conflicts, or drop the details.
I'll drop the details, I think, best to look at it with fresh
perspective if and when we implement it.
> > * Named groups of constraints, provisionally named "roles": Useful for
> > OAOO-ness and reduced typing when scripting or running from the command
> > line; also useful for recording intended machine characteristics when
> > not otherwise translatable (for example, when serialising a deployment
> > as a stack, it would be thoughtful to include a `fast-network` role to
> > hold the `orchestra-classes=rack-c` constraint which *you* know means
> > "next to the switch" but is meaningless to people outside your
> > datacentre).
> If we keep this in the spec, we should include as well a note that
> there are known problems with this approach that may undermine other
> features along the lines of what we discussed, otherwise we're saving
> only the pros and forgetting the cons that the brainstorm has exposed.
Again, I think I'd rather just cut down the spec and discuss the pros
and cons in the appropriate future context.
> > ..  `juju env-set` is intended to take on reponsibility for a number
> > settings previously only exposed via `environments.yaml`; these
> > environment settings will henceforth be exposed via `juju set-env`, and
> > can also be passed into `juju bootstrap`, using the same syntax.
> This still feels like a good idea, but just not for the constraints.
I think we'll definitely want to be able to specify constraints for the
bootstrap node... but, yes, that just means we'll want to "bootstrap
--constraints=", rather than polluting set-env.
I agree it's a good idea, but I think I should take discussion of
set-env out of the spec, because it's no longer actually required.
Thanks again for the scrutiny :-).
More information about the Juju