This section describes the playbooks that are used in the upgrade process in further detail.
Within the main scripts directory there is an upgrade-utilities directory, which contains an additional playbooks directory. These playbooks facilitate the upgrade process.
This playbook is part of the general pre-flight checks.
Because LBaaS v1 isn’t supported in Newton and above, and there is no migration path, the deployer will have to manually disable LBaaS v1 before upgrading. For openstack-ansible, we are checking if neutron_lbaas is set to False, but additional operations are to be done by the deployer for the cleanup.
This calls a script to removes files in /etc/openstack_deploy/ansible_facts/
This playbook backs up the /etc/openstack_deploy directory before changing the configuration.
/etc/openstack_deploy copies once to /etc/openstack_deploy.MITAKA.
This playbook ensures that the user secrets file is updated based on the example file in the main repository, making it possible to guarantee all secrets move into the upgraded environment and generate appropriately. This adds only new secrets, such as those necessary for new services or new settings added to existing services. Values set previously are not changed.
The presence of pip.conf locks down all Python installations to packages on the repo servers. If pip.conf exists on a repo server or a physical node, it will cause a circular dependency issue and the upgrade will fail.
This playbook ensures an alias is created for old hostnames that may not be RFC 1034 or 1035 compatible. Using a hostname alias allows agents to continue working in cases where the hostname is also the registered agent name. This playbook is only needed for upgrades of in-place upgrades of existing nodes or if a node is replaced or rebuilt it will be brought into the cluster using a compliant hostname.
This playbook ensures that all containers are running on the same TZ settings as the physical host.
The playbooks directory contains the setup-infrastructure.yml playbook. The run-upgrade.sh script calls setup-insfrastructure.yml with specific arguments to upgrade MariaDB and RabbitMQ.
For example, to run an upgrade for both components at once, run the following commands:
# openstack-ansible setup-infrastructure.yml -e 'rabbitmq_upgrade=true' \
-e 'galera_upgrade=true'
The rabbitmq_upgrade variable tells the rabbitmq_server role to upgrade RabbitMQ.
Note
The RabbitMQ server role installs patch releases automatically, regardless of the value of rabbitmq_upgrade. This variable only controls upgrading the major or minor versions.
Upgrading RabbitMQ in the Newton release is optional. The run-upgrade.sh script does not automatically upgrade it. To upgrade RabbitMQ, insert the rabbitmq_upgrade: true line into a file, such as: /etc/openstack_deploy/user_variables.yml.
The galera_upgrade variable tells the galera_server role to remove the current version of MariaDB and Galera and upgrade to the 10.x series.
Sends “flush_all” to memcached with the help of nc.
Stops the aodh-api service and removes the init file since aodh-api now runs under Apache mod_wsgi. Run the os-aodh-install.yml playbook during the OpenStack services upgrade to ensure aodh-api is available after running aodh-api-init-delete.yml.
Stops the ceilometer-api service and removes the init file since ceilometer-api now runs under Apache mod_wsgi. Run the os-ceilometer-install.yml playbook during the OpenStack services upgrade to ensure ceilometer-api is available after running ceilometer-api-init-delete.yml.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.