API change: unit and machine nodes

[Gustavo Niemeyer]

> Sorry delayed reply; nice peaceful holiday (still going, technically, but
> whatever ;)).

That's great. Happy new year! :-)

> 1) We have a clear format for constraint specification at environment
> and service levels. ("arch=arm"; "mem="; "ec2-zone=b"; etc).

Which could just as well be specified as:

    {"arch": "arm", "mem": "", "ec2-zone", "b"}

or

    {"mem": "1GB"}

(...)
> 4) To produce an actual machine *specification*, we need to combine env-
> and service-level constraints with the juju defaults, and we also need
> to know the ubuntu series we'll be running.

Exactly! You put two sets of constraints together, add another
computed constraint based on the charm information, and you still have
a set of constraints!

It's ironic that my first message in this thread was a soft hint about
the fact that a dictionary was a better structure to store this kind
of data, and now you've written quite a bit to explain why you
actually want to use a dictionary because it's a more comfortable way
to use this data in other circumstances than the ones foreseen for the
first set of constraints.

Let's turn the conversation into something more tangible.

I propose we use this format to store all of the constraints, in all
of the locations we store them, and that we have a single type that
manages it code-wise:

    {"mem": "1GB", "cpu": "1", "ec2-zone": "b", ...}

Is there any significant problem with doing so?


> It seems that you can see some advantage to further deferring this
> conversion, and that it's compelling enough to make it worth storing the
> data -- which is IMO a very natural dict, at this point -- as a grab-bag

I actually agree.. it's a very natural dict, all along.

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

-- I'm not absolutely sure of anything.