machine placement spec

[Kapil Thangavelu]

Excerpts from William Reade's message of Thu Nov 10 11:48:23 -0500 2011:
> On Thu, 2011-11-10 at 13:18 -0200, Gustavo Niemeyer wrote:
> >
> > We've agreed to keep unit-level constraints out for the moment at the
> > end of the sprint, so it'd be nice to leave them out of the spec as
> > well, so we can avoid getting into details on that. No matter what
> > happens, we have to get service-level constraints right, and the
> > introduction of unit-level constraints down the road, if it turns out
> > to be important, should be made without compromising good behavior of
> > service-level constraints.
> 
> Ah, I'd missed that, thanks. I guess we can still do anything we need by
> tweaking service config before add-unit.
> 

I don't recall that being the conclusion either. We talked about it and the 
ramifications and that for a stack, units would derive from the service settings 
unless they had an explicit unit setting that was portable. Else we prevent 
usage like cross-az.

> > > * additionally, service and environment values should be subsequently
> > > editable with `juju set`, but I understand there's some work to do
> > > before it'll work with environments.
> > 
> > "juju set" changes configuration of services. Not sure if that's the
> > right place for that.
> 
> I had the impression we were in favour of expanding "set" and "get" to
> cover as many cases as possible, to minimise verb count. I'll think some
> more about it.

There was some talk about introducing a namespace to set/get so they could 
maintain universality instead of introducing per usage set/get.

> 
> > > When specified on the command line, each individual constraint is
> > > signalled with `--constraint` or `-c` followed by a `key=value` pair.
> > 
> > What about multiple constraints? Spaces?
> 
> The idea was:
> 
>   juju deploy foo -c ram=512M -c "orchestra-classes=blib blob blub"
> 
> Bad idea, or just badly expressed?

i'm a little concern how well this plays with the argparse impl, but that's an 
implementation detail.

<snip>

> > >  * `place-in=<machine-id>`: On a separate container in the machine with
> > > juju id `machine-id`. Only valid if the machine exists (in juju state),
> > > and is not already holding a unit of the requested service. If
> > 
> > Can we please keep that out as well for now, or rather put it into a
> > future ideas without detailing its semantics?  This is related to
> > multi-unit machines that is not supported right now, and is worth some
> > conversation on itself as the number of exceptions you list on its
> > description clearly indicates.
> 
> 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.
> 
> > >  * `place-with=<service-name>`: On a separate container in *any*
> > 
> > Same thing. Mentioning this is worthwhile for the list and for our
> > history, but I'd keep this in a future ideas section without detailed
> > semantics. We haven't agreed on proper semantics after much
> > discussion, and we don't have to agree on them right now since we
> > won't be implementing it just yet and it won't affect the outcome of
> > the rest of the feature, I believe.
> 
> 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 :( [1].


The network aspects of container isolation are a limiting factor to deploying 
lxc containers.

-k