Chris Friesen <[email protected]> wrote on 04/28/2014 10:44:46 AM:
> On 04/26/2014 09:41 PM, Jay Lau wrote: > ... > > My idea is that can we add a new field such as "PlacemenetPolicy" to > > AutoScalingGroup? If the value is affinity, then when heat engine create > > the AutoScalingGroup, it will first create a server group with affinity > > policy, then when create VM instance for the AutoScalingGroup, heat > > engine will transfer the server group id as scheduler hints so as to > > make sure all the VM instances in the AutoScalingGroup can be created > > with affinity policy. > > While I personally like this sort of idea from the perspective of > simplifying things for heat users, I see two problems. > > First, my impression is that heat tries to provide a direct mapping of > nova resources to heat resources. That matches my understanding too. But autoscaling groups (all three kinds) are already broken in that regard: they are not Nova resources, nor resources of any other service, but purely creatures of Heat's creation. There is a blueprint for fixing this, but it is only very partially implemented at the moment. > 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? Regards, Mike
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
