Open Stack

Chris Friesen <chris.friesen at windriver.com> wrote on 04/30/2014 06:07:49 
PM:

> If we go with what Zane suggested (using the already-exposed 
> scheduler_hints) then by implementing a single "server group" resource 
> we basically get support for server groups "for free" in any resource 
> that exposes scheduler hints.
> 
> That seems to me to be an excellent reason to go that route rather than 
> modifying all the different group-like resources that heat supports.

Yes, I agree there is economy of implementation in that approach.  However 
it seems (to me, anyway) a little awkward from the point of view of the 
template author.  Not terribly so, but a little.  I am generally wary of 
analogies, but I will try to make one that is not much of a stretch. 
Consider a multiple-inheritance class hierarchy where class C inherits 
from A and B; when constructing a C, the user passes the constructor 
parameters of both A and B.  That's fairly natural and usable.  Now 
consider an alternative language that forbids multiple inheritance of 
classes; class A knows that it might work together with a B to accomplish 
what the forbidden C would do; to use the combined functionality the user 
has to construct a B and pass it to the constructor of A.  That works, but 
the language with multiple inheritance is more convenient to use.

Trove and Sahara are not implemented by Heat.  They are going to be more 
interesting cases.

Regards,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/15267f87/attachment.html>