Chris Friesen <[email protected]> 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
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
