ae2b47d8fd
If we call stack_delete on a stack with an operation in progress, we kill any existing delete thread that is running. However, we don't wait for that thread to die before starting a new thread to delete the stack again. If any part of the cleanup operation in the old thread (i.e. handling of the GreenthreadExit exception) causes a context switch (which is likely), other threads can start working while the cleanup is still in progress. This could create race conditions like the one in bug 1328983. Avoid this problem by making sure we wait for all threads in a thread group to die before continuing. (Note that this means the user's API call is blocking on the cleanup of the old thread. This is sadly unavoidable for now, but should probably be fixed in the future by stopping the old thread from the new delete thread.) This was suggested earlier, but removed without explanation between patchsets 11 and 12 of I188e43ad88b98da7d1a08269189aaefa57c36df2, which implemented deletion of in-progress stacks with locks: https://review.openstack.org/#/c/63002/11..12/heat/engine/service.py Also remove the call to stack_lock_release(), which was a hack around the fact that wait() does not wait for link()ed functions - eventlet sends the exit event (that wait() is waiting on) before resolving links. Instead, add another link to the end of the list to indicate that links have all been run. This should eliminate "Lock was already released" messages in the logs. Change-Id: I2e4561cbe29ab10554da67859df8c2db0854dd38 |
||
|---|---|---|
| bin | ||
| contrib | ||
| doc | ||
| etc/heat | ||
| heat | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| babel.cfg | ||
| install.sh | ||
| openstack-common.conf | ||
| pylintrc | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
| uninstall.sh | ||
README.rst
HEAT
Heat is a service to orchestrate multiple composite cloud applications using templates, through both an OpenStack-native ReST API and a CloudFormation-compatible Query API.
Why heat? It makes the clouds rise and keeps them there.
Getting Started
If you'd like to run from the master branch, you can clone the git repo:
git clone git@github.com:openstack/heat.git
- Wiki: http://wiki.openstack.org/Heat
- Developer docs: http://docs.openstack.org/developer/heat
Python client
https://github.com/openstack/python-heatclient
References
- http://docs.amazonwebservices.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html
- http://docs.amazonwebservices.com/AWSCloudFormation/latest/UserGuide/create-stack.html
- http://docs.amazonwebservices.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
- http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca