On 04/26/2014 09:41 PM, Jay Lau wrote:
Just noticed this email, I have already filed a blueprint related to this topic https://blueprints.launchpad.net/heat/+spec/vm-instance-group-supportMy 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. resources: WorkloadGroup: type: AWS::AutoScaling::AutoScalingGroup properties: AvailabilityZones: ["nova"] LaunchConfigurationName: {Ref: LaunchConfig} PlacementPolicy: ["affinity"] <<<<<<<< MaxSize: 3 MinSize: 2
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. Using a property of a heat resource to trigger the creation of a nova resource would not fit that model.
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.
Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
