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.
Also there is no need to resolve outputs data while reset stacks, so set
resolve_data=False when load stack.
Reviewed: https:/ /review. openstack. org/320348 /git.openstack. org/cgit/ openstack/ heat/commit/ ?id=9d239cc80e2 18dd75571e33e51 71f6fee82023b9
Committed: https:/
Submitter: Jenkins
Branch: master
commit 9d239cc80e218dd 75571e33e5171f6 fee82023b9
Author: huangtianhua <email address hidden>
Date: Tue May 24 18:36:46 2016 +0800
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.
Also there is no need to resolve outputs data while reset stacks, so set data=False when load stack.
resolve_
Change-Id: I9379ef6cc6f1d3 bbc2569ff215079 5bfaffee430
Closes-Bug: #1570569