98faacad44
Updating OpenStack (within release) means updating ODL from v1 to v1.1. This is done by "openstack overcloud update" which collects update_tasks. ODL needs 2 different steps to achieve this minor update. These are called Level1 and Level2. L1 is simple - stop ODL, update, start. This is taken care by paunch and no separate implementation is needed. L2 has extra steps which are implemented in update_tasks and post_update_tasks. Updating ODL within the same major release (1->1.1) consists of either L1 or L2 steps. These steps are decided from ODLUpdateLevel parameter specified in environments/services-docker/update-odl.yaml. Upgrading ODL to the next major release (1.1->2) requires only the L2 steps. These are implemented as upgrade_tasks and post_upgrade_tasks in https://review.openstack.org/489201. Steps involved in level 2 update are 1. Block OVS instances to connect to ODL 2. Set ODL upgrade flag to True 3. Start ODL 4. Start Neutron re-sync and wait for it to finish 5. Delete OVS groups and ports 6. Stop OVS 7. Unblock OVS ports 8. Start OVS 9. Unset ODL upgrade flag These steps are exactly same as upgrade_tasks. The logic implemented is: follow upgrade_tasks; when update_level == 2 Change-Id: Ie532800663dd24313a7350b5583a5080ddb796e7 |
||
---|---|---|
ci | ||
common | ||
deployed-server | ||
docker | ||
environments | ||
extraconfig | ||
firstboot | ||
network | ||
plan-samples | ||
puppet | ||
releasenotes | ||
roles | ||
sample-env-generator | ||
scripts | ||
tools | ||
tripleo_heat_templates | ||
validation-scripts | ||
zuul.d | ||
.gitignore | ||
.gitreview | ||
.testr.conf | ||
all-nodes-validation.yaml | ||
babel.cfg | ||
bindep.txt | ||
bootstrap-config.yaml | ||
capabilities-map.yaml | ||
config-download-software.yaml | ||
config-download-structured.yaml | ||
default_passwords.yaml | ||
hosts-config.yaml | ||
j2_excludes.yaml | ||
LICENSE | ||
net-config-bond.j2.yaml | ||
net-config-bridge.j2.yaml | ||
net-config-linux-bridge.j2.yaml | ||
net-config-noop.j2.yaml | ||
net-config-static-bridge-with-external-dhcp.j2.yaml | ||
net-config-static-bridge.j2.yaml | ||
net-config-static.j2.yaml | ||
net-config-undercloud.j2.yaml | ||
network_data_ganesha.yaml | ||
network_data.yaml | ||
overcloud-resource-registry-puppet.j2.yaml | ||
overcloud.j2.yaml | ||
plan-environment.yaml | ||
README.rst | ||
requirements.txt | ||
roles_data_undercloud.yaml | ||
roles_data.yaml | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
Team and repository tags
tripleo-heat-templates
Heat templates to deploy OpenStack using OpenStack.
- Free software: Apache License (2.0)
- Documentation: https://docs.openstack.org/tripleo-docs/latest/
- Source: http://git.openstack.org/cgit/openstack/tripleo-heat-templates
- Bugs: https://bugs.launchpad.net/tripleo
Features
The ability to deploy a multi-node, role based OpenStack deployment using OpenStack Heat. Notable features include:
- Choice of deployment/configuration tooling: puppet, (soon) docker
- Role based deployment: roles for the controller, compute, ceph, swift, and cinder storage
- physical network configuration: support for isolated networks, bonding, and standard ctlplane networking
Directories
A description of the directory layout in TripleO Heat Templates.
- environments: contains heat environment files that can be used with -e
on the command like to enable features, etc.
- extraconfig: templates used to enable 'extra' functionality. Includes
functionality for distro specific registration and upgrades.
- firstboot: example first_boot scripts that can be used when initially
creating instances.
- network: heat templates to help create isolated networks and ports
- puppet: templates mostly driven by configuration with puppet. To use these
templates you can use the overcloud-resource-registry-puppet.yaml.
- validation-scripts: validation scripts useful to all deployment
configurations
- roles: example roles that can be used with the tripleoclient to generate
a roles_data.yaml for a deployment See the roles/README.rst for additional details.
Service testing matrix
The configuration for the CI scenarios will be defined in tripleo-heat-templates/ci/ and should be executed according to the following table:
- | scn001 | scn002 | scn003 | scn004 | scn006 | scn007 | scn009 | non-ha | ovh-ha |
---|---|---|---|---|---|---|---|---|---|
openshift |
|
||||||||
keystone |
|
|
|
|
|
|
|
|
|
glance |
|
swift |
|
|
|
|
|
|
|
cinder |
|
iscsi | |||||||
heat |
|
|
|||||||
ironic |
|
||||||||
mysql |
|
|
|
|
|
|
|
|
|
neutron |
|
|
|
|
|
|
|
|
|
neutron-bgpvpn |
|
||||||||
ovn |
|
||||||||
neutron-l2gw |
|
||||||||
rabbitmq |
|
|
|
|
|
|
|
|
|
mongodb | |||||||||
redis |
|
|
|||||||
haproxy |
|
|
|
|
|
|
|
|
|
memcached |
|
|
|
|
|
|
|
|
|
pacemaker |
|
|
|
|
|
|
|
|
|
nova |
|
|
|
|
ironic |
|
|
|
|
ntp |
|
|
|
|
|
|
|
|
|
snmp |
|
|
|
|
|
|
|
|
|
timezone |
|
|
|
|
|
|
|
|
|
sahara |
|
||||||||
mistral |
|
||||||||
swift |
|
||||||||
aodh |
|
|
|||||||
ceilometer |
|
|
|||||||
gnocchi |
|
|
|||||||
panko |
|
|
|||||||
barbican |
|
||||||||
zaqar |
|
||||||||
ec2api |
|
||||||||
cephrgw |
|
||||||||
tacker |
|
||||||||
congress |
|
||||||||
cephmds |
|
||||||||
manila |
|
||||||||
collectd |
|
||||||||
fluentd |
|
||||||||
sensu-client |
|