[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