Chapter 7. Initial steps for overcloud preparation

You must complete some initial steps to prepare for the overcloud upgrade.

7.1. Preparing for overcloud service downtime

The overcloud upgrade process disables the main services at key points. This means you cannot use any overcloud services to create new resources during the upgrade duration. Workloads running in the overcloud remain active during this period, which means instances continue to run through the upgrade duration.

It is important to plan a maintenance window to ensure no users can access the overcloud services during the upgrade duration.

Affected by overcloud upgrade

  • OpenStack Platform services

Unaffected by overcloud upgrade

  • Instances running during the upgrade
  • Ceph Storage OSDs (backend storage for instances)
  • Linux networking
  • Open vSwitch networking
  • Undercloud

7.2. Selecting Compute nodes for upgrade testing

The overcloud upgrade process allows you to either:

  • Upgrade all nodes in a role
  • Individual nodes separately

To ensure a smooth overcloud upgrade process, it is useful to test the upgrade on a few individual Compute nodes in your environment before upgrading all Compute nodes. This ensures no major issues occur during the upgrade while maintaining minimal downtime to your workloads.

Use the following recommendations to help choose test nodes for the upgrade:

  • Select two or three Compute nodes for upgrade testing
  • Select nodes without any critical instances running
  • If necessary, migrate critical instances from the selected test Compute nodes to other Compute nodes

7.3. Validating the pre-upgrade requirements

Run the pre-upgrade validation group to check the pre-upgrade requirements.


  1. Source the stackrc file.

    $ source ~/stackrc
  2. Run the openstack tripleo validator run command with the --group pre-upgrade option:

    $ openstack tripleo validator run --group pre-upgrade
  3. Review the results of the validation report. To view detailed output from a specific validation, run the openstack tripleo validator show run command against the UUID of the specific validation from the report:

    $ openstack tripleo validator show run <UUID>

A FAILED validation does not prevent you from deploying or running Red Hat OpenStack Platform. However, a FAILED validation can indicate a potential issue with a production environment.

7.4. Disabling fencing in the overcloud

When you upgrade the overcloud, you upgrade each Controller node individually to retain high availability functionality. During this period, the overcloud might detect certain nodes as disabled and attempt fencing operations, which can cause unintended behaviour.

If you have enabled fencing in the overcloud, you must temporarily disable fencing for the duration of the upgrade to avoid any unintended behaviour.


If you use an environment file to enable fencing in your overcloud, the director re-enables fencing during the re-creation of the Controller node cluster.


  1. Log in to the undercloud as the stack user.
  2. Source the stackrc file.

    $ source ~/stackrc
  3. Log in to a Controller node and run the Pacemaker command to disable fencing:

    $ ssh heat-admin@CONTROLLER_IP "sudo pcs property set stonith-enabled=false"

7.5. Creating an overcloud inventory file

Generate an Ansible inventory file of all nodes in your environment with the tripleo-ansible-inventory command.


  1. Log in to the undercloud as the stack user.
  2. Source the stackrc file.

    $ source ~/stackrc
  3. Create a static inventory file of all nodes:

    $ tripleo-ansible-inventory --static-yaml-inventory ~/inventory.yaml --stack STACK_NAME

    If you are not using the default overcloud stack name, set your stack name with the --stack STACK NAME option replacing STACK NAME with the name of your stack.

  4. To execute Ansible playbooks on your environment, run the ansible-playbook command and include the full path of the dynamic inventory tool using the -i option. For example:

    (undercloud) $ ansible-playbook -i ~/inventory.yaml PLAYBOOK