Chapter 25. Performing post-upgrade actions

Procedure

1. Remove the unnecessary packages

   $ sudo dnf -y remove --exclude=python-pycadf-common python2*

2. Remove the content from the /httpboot and /tftpboot directories that includes old images used in Red Hat OpenStack 13:

   $ sudo rm -rf /httpboot /tftpboot

Procedure

1. Check which images you no longer use:

   $ openstack image list
   
   +--------------------------------------+-----------------------------------------+--------+
   | ID                                   | Name                                    | Status |
   +--------------------------------------+-----------------------------------------+--------+
   | 93c156e3-2eae-440b-8fa9-b5aacd15a602 | bm-deploy-kernel                        | active |
   | 59b80e18-6d84-4d81-bfa7-ccdade4b46eb | bm-deploy-kernel_20200922T105130Z       | active |
   | b8c218fb-97d1-4e13-ad15-a94a00fe9354 | bm-deploy-ramdisk                       | active |
   | 1d5b38d1-4a84-48a1-b830-d45643f11a2b | bm-deploy-ramdisk_20200922T105131Z      | active |
   | b87a6265-cf2a-4dfa-9020-c5293300615d | overcloud-full                          | active |
   | c284c181-9dbe-4106-a30b-ac0afd1df96e | overcloud-full_20220822T092204Z         | active |
   | c16f5c7a-02eb-441a-878d-e198b91fc138 | overcloud-full-initrd                   | active |
   | 18d654cd-1c79-4319-bc09-4ffd9da5fdae | overcloud-full-initrd_20220822T092201Z  | active |
   | 5626bb6f-f110-4f34-b961-35b3a6b4fb74 | overcloud-full-vmlinuz                  | active |
   | 90955262-2952-4049-a7ac-b6ee92826ab7 | overcloud-full-vmlinuz_20220822T092159Z | active |
   +--------------------------------------+-----------------------------------------+--------+

2. Delete each legacy image:

   The following example removes all images with a timestamp in their name, such as 20200922T105130Z or 20220822T092159Z:

   $ source ~/stackrc
   $ openstack image list -c Name -f value | egrep "_202[0-9]+T[0-9]+Z" | xargs openstack image delete

   Note

   If you upgraded your environment from RHOSP 13.0 to 16.2, the images do not include timestamps. The following example shows how to remove images with bm-deploy in their name that are also no longer necessary:

   $ openstack image list -c Name -f value | egrep bm-deploy | xargs openstack image delete

Procedure

1. Log in to your undercloud and source the overcloud authentication file:

   $ source ~/overcloudrc

2. Identify the telemetry endpoints that remain after the upgrade:

   $ openstack endpoint list | grep -i -e aodh -e gnocchi -e panko

3. Delete the users of the missing endpoints:

   $ openstack user delete aodh gnocchi panko

Procedure

1. Source the stackrc file.

   $ source ~/stackrc

2. If no inventory file exists, you must generate a static inventory file:

   $ tripleo-ansible-inventory
   --static-yaml-inventory ~$HOME/config-download/<stack_name>/tripleo-ansible-inventory.yaml
   --stack <stack_name>
   --ansible_ssh_user heat-admin

   If you are not using the default overcloud stack name, replace <stack_name> with the name of your stack.

3. Run the openstack tripleo validator run command with the --group post-upgrade option:

   $ openstack tripleo validator run --group {validation} --inventory ~$HOME/config-download/<stack_name>/tripleo-ansible-inventory.yaml

   If you are not using the default overcloud stack name, replace <stack_name> with the name of your stack.

4. Review the results of the validation report. To view detailed output from a specific validation, run the openstack tripleo validator show run --full command against the UUID of the specific validation from the report:

   $ openstack tripleo validator show run --full <UUID>

Procedure

1. Log in to the undercloud as the stack user.

2. Source the stackrc file.

   $ source ~/stackrc

3. Install the packages containing the overcloud QCOW2 archives:

   $ sudo dnf install rhosp-director-images rhosp-director-images-ipa-x86_64

4. Remove any existing images from the images directory on the stack user’s home (/home/stack/images):

   $ rm -rf ~/images/*

5. Extract the archives:

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.2.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.2.tar; do tar -xvf $i; done
   $ cd ~

6. Import the latest images into the director:

   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/

7. Configure your nodes to use the new images:

   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)

Procedure

1. Log in to the undercloud as the stack user.

2. If your Compute nodes support simultaneous multithreading (SMT) but you created instances with the hw:cpu_thread_policy=isolated policy, you must perform one of the following options:

   • Unset the hw:cpu_thread_policy thread policy and resize the instances:

     1. Source your overcloud authentication file:

        $ source ~/overcloudrc

     2. Unset the hw:cpu_thread_policy property of the flavor:

        (overcloud) $ openstack flavor unset --property hw:cpu_thread_policy <flavor>

        Note
        • Unsetting the hw:cpu_thread_policy attribute sets the policy to the default prefer policy, which sets the instance to use an SMT-enabled Compute node if available. You can also set the hw:cpu_thread_policy attribute to require, which sets a hard requirements for an SMT-enabled Compute node.
        • If the Compute node does not have an SMT architecture or enough CPU cores with available thread siblings, scheduling will fail. To prevent this, set hw:cpu_thread_policy to prefer instead of require. The default prefer policy ensures that thread siblings are used when available.
        • If you use hw:cpu_thread_policy=isolate, you must have SMT disabled or use a platform that does not support SMT.

     3. Convert the instances to use the new thread policy.

        (overcloud) $ openstack server resize --flavor <flavor> <server>
        (overcloud) $ openstack server resize confirm <server>

        Repeat this step for all pinned instances using the hw:cpu_thread_policy=isolated policy.

   • Migrate instances from the Compute node and disable SMT on the Compute node:

     1. Source your overcloud authentication file:

        $ source ~/overcloudrc

     2. Disable the Compute node from accepting new virtual machines:

        (overcloud) $ openstack compute service list
        (overcloud) $ openstack compute service set <hostname> nova-compute --disable

     3. Migrate all instances from the Compute node. For more information on instance migration, see Migrating virtual machine instances between Compute nodes.
     4. Reboot the Compute node and disable SMT in the BIOS of the Compute node.
     5. Boot the Compute node.

     6. Re-enable the Compute node:

        (overcloud) $ openstack compute service set <hostname> nova-compute --enable

3. Source the stackrc file:

   $ source ~/stackrc

4. Edit the environment file that contains the NovaVcpuPinSet parameter.

5. Migrate the CPU pinning configuration from the NovaVcpuPinSet parameter to NovaComputeCpuDedicatedSet and NovaComputeCpuSharedSet:

   • Migrate the value of NovaVcpuPinSet to NovaComputeCpuDedicatedSet for hosts that were previously used for pinned instances.
   • Migrate the value of NovaVcpuPinSet to NovaComputeCpuSharedSet for hosts that were previously used for unpinned instances.
   • If there is no value set for NovaVcpuPinSet, then all Compute node cores should be assigned to either NovaComputeCpuDedicatedSet or NovaComputeCpuSharedSet, depending on the type of instances you intend to host on the nodes.

   For example, your previous environment file might contain the following pinning configuration:

   parameter_defaults:
     ...
     NovaVcpuPinSet: 1,2,3,5,6,7
     ...

   To migrate the configuration to a pinned configuration, set the NovaComputeCpuDedicatedSet parameter and unset the NovaVcpuPinSet parameter:

   parameter_defaults:
     ...
     NovaComputeCpuDedicatedSet: 1,2,3,5,6,7
     NovaVcpuPinSet: ""
     ...

   To migrate the configuration to an unpinned configuration, set the NovaComputeCpuSharedSet parameter and unset the NovaVcpuPinSet parameter:

   parameter_defaults:
     ...
     NovaComputeCpuSharedSet: 1,2,3,5,6,7
     NovaVcpuPinSet: ""
     ...

   Important

   Ensure the configuration of either NovaComputeCpuDedicatedSet or NovaComputeCpuSharedSet matches the configuration defined in NovaVcpuPinSet. To change the configuration for either of these, or to configure both NovaComputeCpuDedicatedSet or NovaComputeCpuSharedSet, ensure the Compute nodes with the pinning configuration are not running any instances before updating the configuration.

6. Save the file.

7. Run the deployment command to update the overcloud with the new CPU pinning parameters.

   (undercloud) $ openstack overcloud deploy \
       --stack _STACK NAME_ \
       --templates \
       ...
       -e /home/stack/templates/<compute_environment_file>.yaml
       ...

Procedure

1. List all of the users on your cloud that have the _member_ role:

   openstack role assignment list --names --role _member_ --sort-column project

2. For each user, remove the _member_ role, and apply the member role:

   openstack role remove --user <user> --project <project>  _member_
   openstack role add --user <user> --project <project>  member