machine placement spec

William Reade 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
> constraints.
> 
> As a solution to avoid this, I suggest we create a new command called
> set-constraints that handles that, specifically, with a syntax like
> this:
> 
>     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
> providers.

Sure.

> s/supo/suppo/

Thanks.

> >    * `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
> reliably.

OK.

> >  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
> precedence.

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.

Sounds good.

> > 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.

> > .. [1] `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 :-).

Cheers
William






More information about the Juju mailing list