ed65866d43
Openvswitch package update can be disruptive during update too. So we factor out the code used for upgrade to re-use for update and undercloud update. We also fix a issue where yum/yumdownloader is not available anymore. This cause the special treatment to not happen anymore what not matter what. Instead of duplicating the ansible sequence, this has been ported to a ansible module that replicate the action defined in the templates. We also make sure to not try to restart the openvswitch service if nothing has been changed during the ovs upgrade task. This cover two cases. First, it's an optimization, if nothing has been done, we don't need to check the service. Second, and most importantly, if ovs isn't installed (this can happen on some minimal installation) then we don't try to restart the non-existent service. We keep the tasks at step 3 that make sure again that the openvswitch service is started. This is a failsafe and as such we ignore any error there. This also support the overcloud-minimal type of installation. Depends-On: https://review.opendev.org/743838 Change-Id: I4fde50e353ab7b2e6b03d963f585f6abe35ca32d Closes-Bug: #1888651 Related-Bug: #1888821 (cherry picked from commit |
||
---|---|---|
ci | ||
common | ||
container_config_scripts | ||
deployed-server | ||
deployment | ||
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 | ||
LICENSE | ||
README.rst | ||
all-nodes-validation.yaml | ||
babel.cfg | ||
bindep.txt | ||
capabilities-map.yaml | ||
config-download-software.yaml | ||
config-download-structured.yaml | ||
default_passwords.yaml | ||
j2_excludes.yaml | ||
lower-constraints.txt | ||
net-config-bond.j2.yaml | ||
net-config-bridge.j2.yaml | ||
net-config-linux-bridge.j2.yaml | ||
net-config-noop.j2.yaml | ||
net-config-standalone.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.yaml | ||
network_data_dashboard.yaml | ||
network_data_ganesha.yaml | ||
network_data_routed.yaml | ||
network_data_subnets_routed.yaml | ||
network_data_undercloud.yaml | ||
overcloud-resource-registry-puppet.j2.yaml | ||
overcloud.j2.yaml | ||
plan-environment.yaml | ||
requirements.txt | ||
roles_data.yaml | ||
roles_data_undercloud.yaml | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
README.rst
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: https://opendev.org/openstack/tripleo-heat-templates
- Bugs: https://bugs.launchpad.net/tripleo
- Release notes: https://docs.openstack.org/releasenotes/tripleo-heat-templates/
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:
- | scn000 | scn001 | scn002 | scn003 | scn004 | scn006 | scn007 | scn009 | scn010 | non-ha | ovh-ha |
---|---|---|---|---|---|---|---|---|---|---|---|
keystone |
|
|
|
|
|
|
|
|
|
|
|
glance |
|
swift |
|
|
|
|
|
|
|
||
cinder |
|
iscsi | |||||||||
heat |
|
|
|||||||||
ironic |
|
||||||||||
mysql |
|
|
|
|
|
|
|
|
|
|
|
neutron |
|
|
|
|
|
|
|
|
|
||
neutron-bgpvpn |
|
||||||||||
ovn |
|
||||||||||
neutron-l2gw |
|
||||||||||
om-rpc | rabbit | rabbit |
|
rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | ||
om-notify | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | ||
redis |
|
|
|||||||||
haproxy |
|
|
|
|
|
|
|
|
|
||
memcached |
|
|
|
|
|
|
|
|
|
||
pacemaker |
|
|
|
|
|
|
|
|
|
||
nova |
|
|
|
|
ironic |
|
|
|
|
||
ntp |
|
|
|
|
|
|
|
|
|
|
|
snmp |
|
|
|
|
|
|
|
|
|
|
|
timezone |
|
|
|
|
|
|
|
|
|
|
|
sahara |
|
||||||||||
mistral |
|
||||||||||
swift |
|
||||||||||
aodh |
|
|
|||||||||
ceilometer |
|
|
|||||||||
gnocchi |
|
|
|||||||||
panko |
|
|
|||||||||
barbican |
|
||||||||||
zaqar |
|
||||||||||
ec2api |
|
||||||||||
cephrgw |
|
||||||||||
tacker |
|
||||||||||
cephmds |
|
||||||||||
manila |
|
||||||||||
collectd |
|
||||||||||
designate |
|
||||||||||
octavia |
|