cf465d87b1
Currently when we call the major-upgrade step we do the following:
"""
...
if [[ -n $(is_bootstrap_node) ]]; then
check_clean_cluster
fi
...
if [[ -n $(is_bootstrap_node) ]]; then
migrate_full_to_ng_ha
fi
...
for service in $(services_to_migrate); do
manage_systemd_service stop "${service%%-clone}"
...
done
"""
The problem with the above code is that it is open to the following race
condition:
1. Code gets run first on a non-bootstrap controller node so we start
stopping a bunch of services
2. Pacemaker notices will notice that services are down and will mark
the service as stopped
3. Code gets run on the bootstrap node (controller-0) and the
check_clean_cluster function will fail and exit
4. Eventually also the script on the non-bootstrap controller node will
timeout and exit because the cluster never shut down (it never actually
started the shutdown because we failed at 3)
Let's make sure we first only call the HA NG migration step as a
separate heat step. Only afterwards we start shutting down the systemd
services on all nodes.
We also need to move the STONITH_STATE variable into a file because it
is being used across two different scripts (1 and 2) and we need to
store that state.
Co-Authored-By: Athlan-Guyot Sofer <sathlang@redhat.com>
Closes-Bug: #1640407
Change-Id: Ifb9b9e633fcc77604cca2590071656f4b2275c60
(cherry picked from commit
|
||
|---|---|---|
| deployed-server | ||
| docker | ||
| environments | ||
| extraconfig | ||
| firstboot | ||
| network | ||
| puppet | ||
| tools | ||
| validation-scripts | ||
| .gitignore | ||
| .gitreview | ||
| Gemfile | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| Rakefile | ||
| all-nodes-validation.yaml | ||
| babel.cfg | ||
| bootstrap-config.yaml | ||
| capabilities-map.yaml | ||
| default_passwords.yaml | ||
| hosts-config.yaml | ||
| j2_excludes.yaml | ||
| net-config-bond.yaml | ||
| net-config-bridge.yaml | ||
| net-config-linux-bridge.yaml | ||
| net-config-noop.yaml | ||
| net-config-static-bridge-with-external-dhcp.yaml | ||
| net-config-static-bridge.yaml | ||
| net-config-static.yaml | ||
| overcloud-resource-registry-puppet.j2.yaml | ||
| overcloud.j2.yaml | ||
| requirements.txt | ||
| roles_data.yaml | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
tripleo-heat-templates
Heat templates to deploy OpenStack using OpenStack.
- Free software: Apache license
- Documentation: http://docs.openstack.org/developer/tripleo-docs
- Source: http://git.openstack.org/cgit/openstack/tripleo-heat-templates
- Bugs: http://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