machine placement spec

[Kapil Thangavelu]

Excerpts from William Reade's message of Wed Nov 09 11:24:38 -0500 2011:
> Hi all
> 
> Here's a first attempt at a spec for machine placement. I'd be very
> grateful for your comments, and opinions on which (if any) of the
> described enhancements is valuable enough to be promoted to the main
> part of the spec.
> 
> It's available at docs/source/drafts/placement.rst in
> lp:~fwereade/juju/placement-spec; pasted below for convenience.
> 
> 
> Machine Placement
> =================
> 
> 
> Introduction
> ------------
> 
> At present, juju offers extremely limited tools to those who care what
> sort of hardware their services are run on: only the EC2 provider can
> interpret such requests, and they're of a very limited nature. In
> addition, juju offers no mechanism for placing unbound services on the
> same hardware, and this has been requested often.
> 
> This is an especially painful constraint for those running against
> orchestra in a small data centre with nonhomogenous machines; at this
> end of the spectrum, administrators are much more likely to want to
> control service placement down to the level of individual machines,
> which is impossible within juju. However, even on EC2 some services have
> different requirements to others, and the existing
> `default-instance-type` environment setting is almost entirely
> inadequate.
> 
> This feature will need to cleanly expose different sets of capabilities
> across different providers.
> 

just a few stylistic notes for now.

words extracted from the section above-> limited, impossible, inadequate, 
painful.. seems a bit over dramatic.

i'd focus more on describing the problem keeping in mind this is meant to be 
developer documentation of the feature, post implementation. 

> Constraints
> -----------
> 
> We propose to introduce the concept of "machine constraints", which can
> be used to encode an administrator's hardware requirements. Constraints
> can be set for environments, services, and service units, with lookups
> for each key falling back from more specific to more general settings
> [0]_.


just noting some tense and phrasing throughout..

The spec isn't a sales pitch or proposal. You want discussion around the spec, the 
spec itself isn't a speculative document. Present tense not future. 

compare to
https://juju.ubuntu.com/docs/hook-debugging.html
https://juju.ubuntu.com/docs/drafts/charm-namespaces.html

note the tense... something to cleanup when converting to a rst formatted spec 
in juju/docs.


Looks good!, more comments tomorrow.

cheers,
kapil