46132999c0
While we are careful to ensure there are no race conditions in updating the software deployment metadata in the Heat database, there was no such protection in place for the actual update of the metadata provided to the server via Swift. In legacy Heat, this race could only occur when software deployments were created from the REST API or from separate stacks deploying software to the same server, because resources in the same stack were handled by a single thread making synchronous calls to create the software deployments. However, with convergence, resources in the same stack not only can be processed concurrently but will tend to be synchronised if they have the same dependencies (since they'll be triggered by consecutive asynchronous RPC messages). This handles the race by retrying if a concurrent update is detected by the time the data has been provided to Swift. Note that this is only guaranteed to result in the latest data being available on the assumption that a later write to Swift cannot overwrite an earlier one that has been accepted. This is probably *not* guaranteed by Swift in the presence of clock skew. Nonetheless, this should drastically reduce the failure rate. Similar caveats would probably apply to Zaqar, although Zaqar nominally provides FIFO queues (in practice, it likely depends on the backend used). However, with Zaqar clients receive all updates, not just the latest one, and os-collect-config stores the deployments contained in every message. Thus, Zaqar is not affected even assuming out-of-order arrival. Change-Id: Ic9a447f27e8c51f91f47f93b0fd1e9710341ec38 Closes-Bug: #1731032 |
||
---|---|---|
api-ref/source | ||
bin | ||
contrib/heat_docker | ||
devstack | ||
doc | ||
etc/heat | ||
heat | ||
heat_integrationtests | ||
heat_upgradetests | ||
playbooks/devstack | ||
rally-scenarios | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.stestr.conf | ||
.zuul.yaml | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
README.rst | ||
babel.cfg | ||
config-generator.conf | ||
install.sh | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini | ||
uninstall.sh |
README.rst
Team and repository tags
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 https://git.openstack.org/openstack/heat
- Wiki: http://wiki.openstack.org/Heat
- Developer docs: http://docs.openstack.org/heat/latest
- Template samples: https://git.openstack.org/cgit/openstack/heat-templates
- Agents: https://git.openstack.org/cgit/openstack/heat-agents
Python client
https://git.openstack.org/cgit/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
We have integration with
- https://git.openstack.org/cgit/openstack/python-novaclient (instance)
- https://git.openstack.org/cgit/openstack/python-keystoneclient (auth)
- https://git.openstack.org/cgit/openstack/python-swiftclient (s3)
- https://git.openstack.org/cgit/openstack/python-neutronclient (networking)
- https://git.openstack.org/cgit/openstack/python-ceilometerclient (metering)
- https://git.openstack.org/cgit/openstack/python-aodhclient (alarming service)
- https://git.openstack.org/cgit/openstack/python-cinderclient (storage service)
- https://git.openstack.org/cgit/openstack/python-glanceclient (image service)
- https://git.openstack.org/cgit/openstack/python-troveclient (database as a Service)
- https://git.openstack.org/cgit/openstack/python-saharaclient (hadoop cluster)
- https://git.openstack.org/cgit/openstack/python-barbicanclient (key management service)
- https://git.openstack.org/cgit/openstack/python-designateclient (DNS service)
- https://git.openstack.org/cgit/openstack/python-magnumclient (container service)
- https://git.openstack.org/cgit/openstack/python-manilaclient (shared file system service)
- https://git.openstack.org/cgit/openstack/python-mistralclient (workflow service)
- https://git.openstack.org/cgit/openstack/python-zaqarclient (messaging service)
- https://git.openstack.org/cgit/openstack/python-monascaclient (monitoring service)