On 04/30/2014 03:41 PM, Mike Spreitzer wrote:
Chris Friesen <[email protected]> wrote on 04/28/2014 10:44:46 AM:
> Using a property of a heat resource > to trigger the creation of a nova resource would not fit that model. For the sake of your argument, let's pretend that the new ASG blueprint has been fully implemented. That means an ASG is an ordinary virtual resource. In all likelihood the implementation will generate templates and make nested stacks. I think it is fairly natural to suppose that the generated template could include a Nova server group. > Second, it seems less well positioned for exposing possible server group > enhancements in nova. For example, one enhancement that has been > discussed is to add a server group option to make the group scheduling > policy a weighting factor if it can't be satisfied as a filter. With > the server group as an explicit resource there is a natural way to > extend it. Abstractly an autoscaling group is a sub-class of "group of servers" (ignoring the generalization of "server" in the relevant cases), so it would seem natural to me that the properties of an autoscaling group would include the properties of a server group. As the latter evolves, so would the former. OTOH, I find nothing particularly bad with doing it as you suggest. BTW, this is just the beginning. What about resources of type AWS::CloudFormation::Stack? What about Trove and Sahara?
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.
Chris _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
