Open Stack

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/

- ZB