Open Stack

Just noticed this email, I have already filed a blueprint related to this
topic https://blueprints.launchpad.net/heat/+spec/vm-instance-group-support

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.

resources:
  WorkloadGroup:
    type: AWS::AutoScaling::AutoScalingGroup
    properties:
      AvailabilityZones: ["nova"]
      LaunchConfigurationName: {Ref: LaunchConfig}
      PlacementPolicy: ["affinity"] <<<<<<<<
      MaxSize: 3
      MinSize: 2



2014-04-26 5:27 GMT+08:00 Zane Bitter <zbitter at redhat.com>:

> On 25/04/14 16:07, Chris Friesen wrote:
>
>> On 04/25/2014 12:00 PM, Zane Bitter wrote:
>>
>>> On 25/04/14 13:50, Chris Friesen wrote:
>>>
>>
>>  In the nova boot command we pass the group uuid like this:
>>>>
>>>> --hint group=e4cf5dea-4831-49a1-867d-e263f2579dd0
>>>>
>>>> If we were to make use of the scheduler hints, how would that look?
>>>> Something like this?  (I'm not up to speed on my YAML, so forgive me if
>>>> this isn't quite right.)  And how would this look if we wanted to
>>>> specify other scheduler hints as well?
>>>>
>>>>    cirros_server1:
>>>>      type: OS::Nova::Server
>>>>      properties:
>>>>        name: cirros1
>>>>        image: 'cirros'
>>>>        flavor: 'm1.tiny'
>>>>        scheduler_hints: {"group": { get_resource: my_heat_group }}
>>>>
>>>
>>> Something like that (I don't think you need the quotes around "group").
>>> Or, equivalently:
>>>
>>>    cirros_server1:
>>>      type: OS::Nova::Server
>>>      properties:
>>>        name: cirros1
>>>        image: 'cirros'
>>>        flavor: 'm1.tiny'
>>>        scheduler_hints:
>>>          group: { get_resource: my_heat_group }
>>>
>>>
>> Okay...assuming it works like that then that looks fine to me.
>>
>
> Cool, +1 for that then.
>
>
>  If we go this route then the changes are confined to a single new file.
>>   Given that, do we need a blueprint or can I just submit the code for
>> review once I port it to the current codebase?
>>
>
> I guess wearing my PTL hat I ought to say that you should still raise a
> blueprint (no real content necessary though, or just link to this thread).
>
> Wearing my core team hat, I personally couldn't care less either way ;)
> The change is self-explanatory and you've already done a good job of
> consulting on the changes before submitting them.
>
> cheers,
> Zane.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140427/918d1a6e/attachment.html>