OpenStack Orchestration (Heat)
f3b8e93238
These support classes started as a forklift of the classes needed to run tempest scenario orchestration tests. The original tempest code has been pared back to provide the small subset required by heat integration tests. From this point on these support classes can evolve to the specific needs of the integration tests. There is some unused code (especially in remote_client) which has been left in as it may become useful in the future, and is already extremely well reviewed and tested from being developed for tempest. The script heat_integrationtests/generate_sample.sh will generate an up-to-date heat_integrationtests/heat_integrationtests.conf.sample file which can be copied to heat_integrationtests/heat_integrationtests.conf to override default configuration values. A local ConfigOpts is created for each test to avoid any potential interaction with heat's global CONF. Configuration options for credentials default to being sourced from the environment. The default tox testenv now excludes tests in heat_integrationtests. A new testenv called "integration" will only run tests in heat_integrationtests. Integration tests will fail if preconditions are not met, including a keystone endpoint, credentials and glance containing the expected named image. Devstack gate hooks have been moved to heat_integrationtests now that the name of the package has been decided. Change-Id: I174429c16bb606c5c325ee8b62c6e600ea77a6e6 Partial-Blueprint: functional-tests |
||
---|---|---|
bin | ||
contrib | ||
doc | ||
etc/heat | ||
heat | ||
heat_integrationtests | ||
rally-scenarios | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.testr.conf | ||
babel.cfg | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
install.sh | ||
LICENSE | ||
MANIFEST.in | ||
openstack-common.conf | ||
pylintrc | ||
README.rst | ||
requirements.txt | ||
run_tests.sh | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini | ||
uninstall.sh |
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
We have integration with
- https://github.com/openstack/python-novaclient (instance)
- https://github.com/openstack/python-keystoneclient (auth)
- https://github.com/openstack/python-swiftclient (s3)
- https://github.com/openstack/python-neutronclient (networking)
- https://github.com/openstack/python-ceilometerclient (metering)
- https://github.com/openstack/python-cinderclient (storage service)
- https://github.com/openstack/python-glanceclient (image service)
- https://github.com/openstack/python-troveclient (database as a Service)