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


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to