API change: unit and machine nodes

William Reade william.reade at canonical.com
Fri Dec 23 12:07:02 UTC 2011

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

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.

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.

Any objections?


[0] Not yet implemented.

More information about the Juju mailing list