The resetting of in-progress stacks at startup is done using an admin
context. No user actions (e.g. ReST API calls) are performed, so there is
no need to load the user context that is stored with the stack. (Nor is the
current context rewritten to the database in the process of resetting the
state.)
Since loading the user context from the DB may result in a call to the
keystone API, eliminating this ensures that stacks can be reset
successfully even if heat-engine starts before keystone is available.
Reviewed: https:/ /review. openstack. org/317604 /git.openstack. org/cgit/ openstack/ heat/commit/ ?id=026cc94eba4 8364b35a561fd21 e33d6d482ab39d
Committed: https:/
Submitter: Jenkins
Branch: master
commit 026cc94eba48364 b35a561fd21e33d 6d482ab39d
Author: Zane Bitter <email address hidden>
Date: Tue May 17 11:08:03 2016 -0400
Don't use stored context to reset stacks
The resetting of in-progress stacks at startup is done using an admin
context. No user actions (e.g. ReST API calls) are performed, so there is
no need to load the user context that is stored with the stack. (Nor is the
current context rewritten to the database in the process of resetting the
state.)
Since loading the user context from the DB may result in a call to the
keystone API, eliminating this ensures that stacks can be reset
successfully even if heat-engine starts before keystone is available.
Change-Id: I8109c622b76612 54a658d78d98f8d c8f756d8755
Closes-Bug: #1570569