[openstack-dev] [heat] as-update-policy implementation questions

Zane Bitter zbitter at redhat.com
Fri Jun 7 09:03:10 UTC 2013


On 07/06/13 02:23, Angus Salkeld wrote:
> On 06/06/13 17:50 +0000, Chan, Winson C wrote:
>> Heat team,
>>
>> Regarding blueprint
>> https://blueprints.launchpad.net/heat/+spec/as-update-policy, can you
>> answer the following so to help me speed up where to look?
>>
>> 1) I'm currently thinking that the UpdatePolicy would be enforced (if
>> defined in the stack template) at either AutoScalingGroup.adjust or
>> InstanceGroup.resize in ./heat/engine/resources/autoscaling.py.  I'm
>> trying to understand the flow.  It's not obvious to me where in the
>> cloud watch code that invoke the adjust or resize method when alarm
>> condition is met.  Can you point me in the right direction?
>
> Hi Winson,
>
> This is where the new alarm state gets evaluated:
> https://github.com/openstack/heat/blob/master/heat/engine/watchrule.py#L218
>
> This is where the actions are added:
> https://github.com/openstack/heat/blob/master/heat/engine/watchrule.py#L242
>
> This is where the actions are run:
> https://github.com/openstack/heat/blob/master/heat/engine/service.py#L546

I think you're already aware of this, but just to clarify: the 
UpdatePolicy controls stack updates, not autoscaling events, so 
presumably you are looking for the alarm-triggered resize code to make 
sure these changes _don't_ go into that path.
>
>>
>> 2) Since this relates to rolling update, I need to keep the
>> adjust/resize task in the scheduler until it completed the rolling
>> update.  Do I use the TaskRunner and set up steps in the task with
>> sleep in between steps according to the UpdatePolicy?

Just sleeping would work for now, but I'm also currently working on 
making stack updates happen in parallel the way the stack creates now 
do. So what you probably want to do is start a timer and just yield 
until it expires (I suggest you use the scheduler.Timeout class for this 
- no need to raise it as an exception), then go on to process the next 
batch. When Resource.update() becomes a coroutine, this will allow any 
other resources that are being updated at the same time to continue 
updating in parallel.

cheers,
Zane.



More information about the OpenStack-dev mailing list