preliminary machine placement discussion

Kapil Thangavelu kapil.thangavelu at canonical.com
Thu Nov 10 04:01:04 UTC 2011


Excerpts from William Reade's message of Wed Nov 09 05:11:18 -0500 2011:

<snip spec agreement> 
<dive into roles>

 > 
> > > So... what can we do? While I hate to introduce another new concept, I
> > > think it's justified here: we want to be able to group constraints as
> > > "roles". This has two notable advantages:
> > > 
> > > * We can simplify command lines -- considering all the other possible
> > > options we already handle, it'll be quite convenient to be able to do
> > > things like:
> > > 
> > >   juju set-role compute --constraint cores=128,ram=64G
> > >   juju deploy nova-compute --role compute
> > >   juju set-role compute-spike --constraint cores=32
> > >   juju add-unit nova-compute --role compute-spike
> > > 
> > > ...or even:
> > > 
> > >   juju set-role compute --constraint cores=128,ram=64G
> > >   juju set-role compute-spike --constraint cores=32
> > >   juju deploy nova-compute --role compute
> > >   ...
> > >   juju set nova-compute --role compute-spike
> > >   juju add-unit nova-compute
> > >   juju add-unit nova-compute
> > >   ...
> > >   juju add-unit nova-compute
> > > 

Its not clear this is actually easier or just introducing additional cli 
commands and concepts.

ie. the first example is just

juju deploy nova-compute --constraint cores=128,ram64G
juju deploy add-unit nova-compute --constraint cores=32,ram64G

the second example simplifies with the ability to set the service deploy 
settings for new units instead of defining the additional role.


> > hmm.. a purely semantic intent against an unstructured vocabuarly?
> 
> Yes, tailor-made for interpretation by a massively-parallel pattern
> matcher and inference engine, likely to be capable of translating that
> semantic intent into relevant datacentre-specific constraints.
> 

:-) the million monkeys can write shakespeare, but they can't perform it very 
well.


> Indeed so -- I see it as a valuable way of exposing a stack's
> requirements at the human level so that, when deploying a new stack in
> your own environment, you don't necessarily need to think about every
> service. It's potentially somewhat niche -- it assumes that relatively
> complex stacks are likely to have multiple services with similar
> requirements, and that it will be useful to say things like "all these
> services should just run on m1.smalls".

Given that its unconstrained, people will use it to represent meaningful things 
in their environment. ie. i have three different types of hardware, so i have 
three different roles (dell-x, hp-y, ibm-z) that i use for my services and 
units. Those maybe be bad role names for portability, but they made 
sense in that environment. What value does an exported stack of such have? 
Somebody wants to use it in a cloud environment now.. Did the roles add to its 
portability or aid in semantic understanding or management for a user of this stack? 

If the intent is semantic capture, it seems better just tagging the 
service with a text note for the purpose explicitly. 

> 
> > The concept of roles don't seem like they address the provider specific 
> > vocabulary question, the additional semantic capture in a unstructured 
> > vocabulary label requires human inspection and interpretation as well as 
> > management of the value. I'd like to just be able to deploy a 3rd party stack 
> > directly.
> 
> Definitely: the intent is to allow you to *tweak* a stack's deployment
> constraints at a convenient level. I agree that a stack should be
> deployable in a sensible configuration *without* needing this feature,
> but I also think named sets of constraints will be useful (if not
> actually *necessary*) both for stacks and for ad-hoc use in normal
> environments.
> 

i do see some value in roles for the edit scenario, given an export with a few 
hundred services, effectively even ignoring the roles names, they are just 
abstract resource classifications with some relative weighting, that a user can 
assign constraint values on. 

its not clear if this convenient level of tweaking isn't really just a ui design 
that could be implemented at stack import time instead of incorporating 
into day to day management of the evironment. ie abstract role creation 
at import time via grouping similiar resource usage. in that context its really 
about a group editing and labeling ui.

cheers,

Kapil



More information about the Juju mailing list