<tt><font size=2>Chris Friesen <chris.friesen@windriver.com> wrote
on 04/30/2014 06:07:49 PM:<br>
</font></tt>
<br><tt><font size=2>> If we go with what Zane suggested (using the
already-exposed <br>
> scheduler_hints) then by implementing a single "server group"
resource <br>
> we basically get support for server groups "for free" in
any resource <br>
> that exposes scheduler hints.<br>
> <br>
> That seems to me to be an excellent reason to go that route rather
than <br>
> modifying all the different group-like resources that heat supports.<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Trove and Sahara are not implemented by Heat.  They
are going to be more interesting cases.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>