API change: unit and machine nodes

[Gustavo Niemeyer]

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

It feels strange to be storing exactly the same type of information in
different formats depending on where we're looking at. I suggest
storing the unaltered strings in the former format across the board.

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

Agreed, it should be the single final list, but in a consistent format.

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

It sounds clearer, and at least partially sane, thanks. :-)

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

-- I'm not absolutely sure of anything.