API change: unit and machine nodes

[Gustavo Niemeyer]

Hey William,

> I propose that machine constraints be stored both in ServiceUnitState
> nodes, and MachineState nodes, as dictionaries of final constraints.
>
> That is: when a unit is added, the prevailing constraints from juju
> itself, from the environment [0], and from the service should be
> collapsed into a single final dictionary and stored in the node, under
> the key "constraints".

I assume that you mean "store in the unit node" above, right?

Sounds good.

> Similarly, when a machine state node is created (generally because a new
> unit state needs a machine to be assigned to) the necessary constraints
> can be copied from the unit state to the machine state's "constraints"
> key, so the provisioning agent can know how to actually provision the
> new machine.

Sounds good as well.

> Note that this is different from the service state constraints storage
> (lists of strings, representing exactly what the user asked for at
> service level); this is entirely because service (and eventually
> environment) constraints are "input" data, and are kept in their
> original format for transparency and consistency's sake; but, once we're
> dealing with unit/machine state, we're storing "output" data... ie the
> actual constraints calculated from all levels' input. Once a unit has
> been added, and/or a machine set up for provisioning, subsequent changes
> to environment/service constraints should not affect the units/machines;
> and once we're past the point at which the multiple levels of
> constraints have been collapsed, it seems a touch perverse to maintain
> them in uncollapsed form when we're only interested in the collapsed
> form anyway.

I don't understand what you mean here. What's collapsed form and
what's uncollapsed form?

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

-- I'm not absolutely sure of anything.