[openstack-dev] [heat][sahara][magnum][tripleo] Scaling nested stack validation

Zane Bitter zbitter at redhat.com
Mon Apr 3 19:39:03 UTC 2017


On 28/11/16 14:20, Zane Bitter wrote:
> On 23/11/16 17:58, Zane Bitter wrote:
>> I also investigated another issue, which is that since the fix for
>> https://bugs.launchpad.net/heat/+bug/1388140 landed (in Kilo) I believe
>> we are validating nested stacks multiple times (specifically, m times,
>> where m is the stack's depth in the tree):
>>
>>   root                     child                    grandchild
>>
>>   create
>>    -> validate ----------> validate --------------> validate
>>    -> Resource.create ===> create
>>                             -> validate ----------> validate
>>                             -> Resource.create ===> create
>>                                                      -> validate
>>
>> The only good news here is that ResourceGroup is smart enough to make
>> sure that it generates a nested stack with at most 1 resource to
>> validate when validate() is called. (However, when the nested stack is
>> created, and thus validated, it is of course full-sized.) Autoscaling
>> groups make no such allowances, but the patch above should actually have
>> the same effect. (We can't get rid of the special case for ResourceGroup
>> though, because of index substitution.)
>>
>> An obvious fix would be to disable validation - or, more specifically,
>> validation of _resources_ - on create/update for stacks that have a
>> non-null owner_id (i.e. nested stacks), so that we had something like:
>>
>>   root                     child                    grandchild
>>
>>   create
>>    -> validate ----------> validate --------------> validate
>>    -> Resource.create ===> create
>>                             -> Resource.create ===> create
>>
>> That would eliminate the duplication/triplication/multiplication of
>> validation. It would also mean that we'd cut out the expensive part of
>> ResourceGroup validation with index substitution, leaving only the cheap
>> part.
>>
>> One downside is that in the ResourceGroup/index substitution case we'd
>> be creating resources whose definitions hadn't _ever_ been validated. I
>> _think_ that's safe, in the sense that you'd just hear about errors
>> later, as opposed to everything falling over in a heap, but it's
>> difficult to be certain. Hearing about problems late is also not ideal
>> (since it may cause otherwise-healthy siblings to be cancelled), but I
>> would guess that heavy users like TripleO developers would say that it's
>> worth the tradeoff.
>
> https://launchpad.net/bugs/1645336
> https://review.openstack.org/#/c/403828/

It turned out to be more subtle than that:
https://bugs.launchpad.net/heat/+bug/1675589

Global state sucks.

- ZB




More information about the OpenStack-dev mailing list