Jesse Pretorius 3fb15ad780 Clean-up and simplify the major upgrade
The major upgrade procedure has been collecting new bits over time,
but has not really had bits cleaned out of it when unnecessary. Some
parts have also never been used.

This patch does the following:

1.  Consolidates the basic deploy node changes into a single playbook
    which is tagged, and therefore easy to run stand alone and use
    with skip-tags if necessary.
2.  Removes the ceph-galaxy-removal playbook which was for the P->Q
    upgrade only.
3.  Removes the ansible_fact_cleanup playbook and script - the first
    ran the second which was a bit pointless, given it could be done
    in a playbook task instead. This has been rolled into the
    deploy-config-changes playbook.
4.  Removes the memcached-flush playbook which was only actually
    required for the N->O upgrade. The functionality to enable the
    flush more surgically was enabled via a var in the keystone role
    in [a], so that can be used in the future if need be.
5.  Consolidates user-secrets-adjustment into the
    deploy-config-changes playbook, and also removes the var renames
    which were only appropriate for the Q->R upgrade.
6.  Removes the make_rst_table, migrate_openstack_vars and
    test_migrate_openstack_vars scripts which do not ever appear to
    have been used.
7.  Changes the limited playbook run for galera_all/rabbitmq_all from
    only doing lxc-containers-create.yml to all of setup_hosts to
    ensure that any hosts missed out in the previous step is handled
    in that step. This is useful if rabbitmq/galera are installed on
    hosts instead of in containers.
8.  Removed the extra backup of the /etc/openstack_deploy directory
    given that it is already archived by the run-upgrade script.
9.  Made the backup of the OSA configuration done in run-upgrade
    idempotent.
10. Removes the reference content for upgrades, given that most of
    it is duplicated and the simplified structure negates the need
    for a reference guide.
11. Change the infrastructure part of the upgrade to be simpler,
    and use the setup-infrastructure playbook.

[a] https://review.openstack.org/#/q/topic:bug/1793389
Related-Bug: #1808041
Change-Id: I58732dc181ee985364e97aa890987a98544ed06c
2019-01-23 10:45:09 +00:00

141 lines
3.6 KiB
ReStructuredText

=====================
Minor version upgrade
=====================
Upgrades between minor versions of OpenStack-Ansible require
updating the repository clone to the latest minor release tag, updating
the ansible roles, and then running playbooks against the target hosts.
This section provides instructions for those tasks.
Prerequisites
~~~~~~~~~~~~~
To avoid issues and simplify troubleshooting during the upgrade, disable the
security hardening role by setting the ``apply_security_hardening`` variable
to ``False`` in the :file:`user_variables.yml` file, and
backup your openstack-ansible installation.
Execute a minor version upgrade
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A minor upgrade typically requires the following steps:
#. Change directory to the cloned repository's root directory:
.. code-block:: console
# cd /opt/openstack-ansible
#. Ensure that your OpenStack-Ansible code is on the latest
|current_release_formal_name| tagged release:
.. parsed-literal::
# git checkout |latest_tag|
#. Update all the dependent roles to the latest version:
.. code-block:: console
# ./scripts/bootstrap-ansible.sh
#. Change to the playbooks directory:
.. code-block:: console
# cd playbooks
#. Update the hosts:
.. code-block:: console
# openstack-ansible setup-hosts.yml
#. Update the infrastructure:
.. code-block:: console
# openstack-ansible -e rabbitmq_upgrade=true \
setup-infrastructure.yml
#. Update all OpenStack services:
.. code-block:: console
# openstack-ansible setup-openstack.yml
.. note::
You can limit upgrades to specific OpenStack components. See the following
section for details.
Upgrade specific components
~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can limit upgrades to specific OpenStack components by running each of the
component playbooks against groups.
For example, you can update only the Compute hosts by running the following
command:
.. code-block:: console
# openstack-ansible os-nova-install.yml --limit nova_compute
To update only a single Compute host, run the following command:
.. code-block:: console
# openstack-ansible os-nova-install.yml --limit <node-name> \
--skip-tags 'nova-key'
.. note::
Skipping the ``nova-key`` tag is necessary so that the keys on
all Compute hosts are not gathered.
To see which hosts belong to which groups, use the ``inventory-manage.py``
script to show all groups and their hosts. For example:
#. Change directory to the repository clone root directory:
.. code-block:: console
# cd /opt/openstack-ansible
#. Show all groups and which hosts belong to them:
.. code-block:: console
# ./scripts/inventory-manage.py -G
#. Show all hosts and the groups to which they belong:
.. code-block:: console
# ./scripts/inventory-manage.py -g
To see which hosts a playbook runs against, and to see which tasks are
performed, run the following commands (for example):
#. Change directory to the repository clone playbooks directory:
.. code-block:: console
# cd /opt/openstack-ansible/playbooks
#. See the hosts in the ``nova_compute`` group that a playbook runs against:
.. code-block:: console
# openstack-ansible os-nova-install.yml --limit nova_compute \
--list-hosts
#. See the tasks that are executed on hosts in the ``nova_compute`` group:
.. code-block:: console
# openstack-ansible os-nova-install.yml --limit nova_compute \
--skip-tags 'nova-key' \
--list-tasks