machine placement spec

Thu Nov 10 18:14:11 UTC 2011

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

"minimizing verb count" is not a good design guideline to take as a
priority. I know it sounds a bit cheesy, but the priority is doing
sensible things, and each context tends to have a different idea of
what sensible means.

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

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

> 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 [0]
(...)

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

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

Cheers!

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

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

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.

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

> Special API may not be a dependency, but the actual information
> defnitely is.

Right, agreed.

> 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
yet?

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

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

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

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.