machine placement spec

[Gustavo Niemeyer]

> Expand please? If we're expressing them in stacks or charms I think I'd
> rather have a yaml list of distinct constraints than to smush them all
> together and have to parse them out myself, and to my eye it's quite
> convenient and readable to have a separate command-line option for each
> constraint.

Parsing the format is trivial:

    --constraints "cpu=2 mem=4GB"

In yaml:

    constraints: cpu=2 mem=4GB

In the environment:

    export CONSTRAINTS="cpu=2 mem=4GB"

etc.


> resetting constraints every time you deploy). Caveats remain, though:
>
> 1) I don't see a significant distinction between a constraint that
(...)
> 2) The effort is not equivalent: cobbler machines always have names
(...)
> 3) Using mgmt-classes would therefore be frustrating and

You make good points. +1 on the option.

> "Sharing constraints"?

Co-location constraints? :-)

I'd vote for using the term co-location to refer to the concept of
co-location generically (slave or not). That's how people hear it
anyway.

> Not really -- it's just one of the parts of orchestra that we interact
> with (the other is the webdav storage). My understanding is that it may
> be simpler/cleaner for them to expose the information without modifying
> cobbler, but I'd have to defer to someone who knew the details to
> explain why.

I imagined they'd just stick the extra metadata into an existing field.

> Yeah, plausible; I'll think about it. I'm not sure whether we reached
> consensus about how to restructure environment settings yet; that is
> definitely a prerequisite for this feature.

Indeed on both counts.

> A number of constraints can interact badly: "ram=64G" and
> "ec2-instance-type=m1.small", for example, cannot both be satisfied. IMO

This doesn't have to be a conflict. I'd pick ec2-instance-type if
running on EC2 since it's most specific, and drop ram. In other
providers, I'd keep ram. This is much more useful then breaking down
if the user selects both.

> the deciding factor should be "is `max` actually useful?" rather than
> "does `max` allow people people to express unlikely requirements?".

Ok, it's a valid suggestion either way.

> Excellent; expect a new draft with the settled points imminently.

Cheers!

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

-- I'm not absolutely sure of anything.