ced6f78aa0
Before creating a nested stack we validate the resources in the parent stack. Therefore it's wasteful to validate them again upon creating the stack - prior to this patch the number or validation calls for each resource would be equal to the depth of the stack in the tree (so twice for a child of the root, and three times for a grandchild). With this patch, each resource in a nested stack is validated only once, by the parent resource. ResourceGroup and its subclasses are currently the only StackResources that do not validate all of their members; they validates a stack containing a single representative resource. This means that in the case of e.g. index substitution, the nested stack could be created without having validated some resources. However, in practice this is unlikely to lead to validity problems not causing a failure until later than they previously would have. Change-Id: Iaa36ae5543b3ce30ae8df5a05b48fe987bc0ffdc Closes-Bug: #1645336 |
||
---|---|---|
api-ref/source | ||
bin | ||
contrib | ||
devstack | ||
doc | ||
etc/heat | ||
heat | ||
heat_integrationtests | ||
heat_upgradetests | ||
install-guide/source | ||
rally-scenarios | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
README.rst | ||
babel.cfg | ||
bandit.yaml | ||
config-generator.conf | ||
install.sh | ||
pylintrc | ||
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/developer/heat
- Template samples: https://git.openstack.org/cgit/openstack/heat-templates
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)
- https://git.openstack.org/cgit/openstack/python-senlinclient (clustering service)