API change: unit and machine nodes

William Reade william.reade at canonical.com
Fri Dec 23 12:48:36 UTC 2011

On Fri, 2011-12-23 at 10:14 -0200, Gustavo Niemeyer wrote:
> I don't understand what you mean here. What's collapsed form and
> what's uncollapsed form?

Sorry :).

Uncollapsed (env-level/service-level) form is a list of validated, but
unaltered, strings; exactly as specified by the user (and agreed upon a
few days ago):

  ["mem=16G", "cpu=20"]

Collapsed (unit/machine) form is:

  {"arch": None, "cpu": 20, "mem": 16384, "ec2-zone": None,
"ec2-instance-type": None, "ubuntu-series": "oneiric"}

...that is, it contains (1) actual parsed values; (2) Nones for
everything left unspecified; (3) the series the charm expects/needs to
run on.

[aside re series: the PA needs to know this to provision correctly, and
it's available from the charm id at the point the unit is added; and so
it seemed most sensible to bake it into the final constraints at that
point. IMO it unquestionably is a system constraint, and should be
treated as such; it just isn't one we want to allow users to specify
(directly), because it depends entirely on the charm we want to run.]

When we store machine/unit data, we *could* just store 2 levels of
uncollapsed data (and just add the series to the machine, because it's
already implicitly available on the unit) -- and reconstruct dicts for
provisioning/comparison on demand -- but again I don't really see the
benefit; once we have all the data we need, we can smoosh it all into a
single dict and work with that dict alone.

Does that sound any saner/clearer?


More information about the Juju mailing list