Chapter 8. Overcloud adoption and preparation
Perform the overcloud adoption and upgrade preparation on each stack in your environment. To perform the overcloud adoption and upgrade preparation in a DCN environment, see Overcloud adoption and preparation in a DCN environment.
For information about the duration and impact of this upgrade procedure, see Upgrade duration and impact.
8.1. Performing the overcloud adoption and preparation Copy linkLink copied to clipboard!
You must perform the following tasks for overcloud adoption:
- On each stack, adopt the network and host provisioning configuration exports into the overcloud.
- Define new containers and additional compatibility configuration.
After adoption, you must run the upgrade preparation script, which performs the following tasks:
- Updates the overcloud plan to OpenStack Platform 17.1
- Prepares the nodes for the upgrade
For information about the duration and impact of this upgrade procedure, see Upgrade duration and impact.
If your roles include a large number of nodes, you can accelerate the RHOSP upgrade by splitting existing roles and dividing the nodes between the roles. For more information, see the Red Hat Knowledgebase solution How to split roles during upgrade from RHOSP 16.2 to RHOSP 17.1.
Prerequisites
-
Confirm that all bare-metal provisioned nodes are in the
ACTIVEstate. If any nodes remain in theMAINTENANCEstate, you cannot proceed with the upgrade. For more information about setting the nodes toACTIVE, see Setting bare-metal provisioned nodes to the active state.
Procedure
-
Log in to the undercloud host as the
stackuser. Source the
stackrcundercloud credentials file:$ source ~/stackrcVerify that the following files that were exported during the undercloud upgrade contain the expected configuration for the overcloud upgrade. You can find the following files in the
~/overcloud-deploy/$(<stack>)directory:-
tripleo-<stack>-passwords.yaml -
tripleo-<stack>-network-data.yaml -
tripleo-<stack>-virtual-ips.yaml -
<stack>-network-environment.yaml tripleo-<stack>-baremetal-deployment.yaml-
Replace
<stack>with the name of your stack. -
Check that the mappings between the baremetal node UUIDs, hostnames, and IP addresses in the
tripleo-<stack>-baremetal-deployment.yamlfile match your current overcloud. Correct the mappings if required. -
If the
tripleo-<stack>-passwords.yamlfile does not exist, review the resolution in the Red Hat Knowledgebase article Create a missing overcloud password file.
-
Replace
WarningYou must address the issues in Jinja2 comments, and then remove all Jinja2 comment blocks, from each nic-config template that is created by automated conversion tools such as
convert_v1_net_data.pyorconvert_heat_nic_config_to_ansible_j2.pyduring the undercloud upgrade. If you do not remove these comment blocks, scaled-out nodes fail to provision, or you can lose control plane networking ifnetwork_config_updateis set totrue.{{# NOTE! Custom parameter {} was hard-coded in ' 'the converted template. To parameterize use the ' '{{role.name}}ExtraGroupVars THT interface and update the ' 'template to use an ansible var. +#}}-
On the main stack, copy the
passwords.yamlfile to the~/overcloud-deploy/$(<stack>)directory. Repeat this step on each stack in your environment:$ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-passwords.yaml ~/overcloud-deploy/<stack>/<stack>-passwords.yamlOn the main stack, copy the
network-data.yamlfile to the stack user’s home directory and deploy the networks. Repeat this step on each stack in your environment:$ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-network-data.yaml ~/ $ openstack overcloud network provision --debug \ --output /home/stack/templates/generated-networks-deployed.yaml tripleo-<stack>-network-data.yamlFor more information, see Provisioning and deploying your overcloud in Installing and managing Red Hat OpenStack Platform with director.
If your environment has pre-provisioned nodes, complete the following steps:
Make a backup copy of the
tripleo-<stack>-virtual-ips.yamlfile in the stack user’s home directory:$ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-virtual-ips.yaml ~/ ~/overcloud-deploy/<stack>/tripleo-<stack>-virtual-ips.yaml.origInclude the following configuration at the end of the
tripleo-<stack>-virtual-ips.yamlfile:dns_name: overcloud ip_address: <ctrlplane_virtual_ip>1 name: control_virtual_ip2 network: ctlplane subnet: ctlplane-subnet
On the main stack, copy the
virtual-ips.yamlfile to the stack user’s home directory and provision the network VIPs. Repeat this step on each stack in your environment:$ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-virtual-ips.yaml ~/ $ openstack overcloud network vip provision --debug \ --stack <stack> --output \ /home/stack/templates/generated-vip-deployed.yaml tripleo-<stack>-virtual-ips.yamlOn the main stack, copy the
network-environment.yamlfile to the stack user’s home directory. Repeat this step on each stack in your environment:$ cp ~/overcloud-deploy/<stack>/<stack>-network-environment.yaml ~/templates/<stack>-network-environment.yamlNoteEnsure that the
NetworkConfigTemplateparameters point to the generated.j2files and that you delete theresource_registrymappings in theovercloud-network-environment.yamlfile. For more information, see Manually converting NIC templates to Jinja2 Ansible format in Customizing your Red Hat OpenStack Platform deployment.On the main stack, copy the
baremetal-deployment.yamlfile to the stack user’s home directory and provision the overcloud nodes. Repeat this step on each stack in your environment:$ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-baremetal-deployment.yaml ~/ $ openstack overcloud node provision --debug --stack <stack> \ --output /home/stack/templates/baremetal-deployment.yaml \ tripleo-<stack>-baremetal-deployment.yamlNoteThis is the final step of the overcloud adoption. If your overcloud adoption takes longer than 10 minutes to complete, contact Red Hat Support.
Complete the following steps to prepare the containers:
Back up the
containers-prepare-parameter.yamlfile that you used for the undercloud upgrade:$ cp containers-prepare-parameter.yaml \ containers-prepare-parameter.yaml.origDefine the following environment variables before you run the script to update the
containers-prepare-parameter.yamlfile:-
NAMESPACE: The namespace for the UBI9 images. For example,NAMESPACE='"namespace":"example.redhat.com:5002",' -
EL8_NAMESPACE: The namespace for the UBI8 images. -
NEUTRON_DRIVER: The driver to use and determine which OpenStack Networking (neutron) container to use. Set to the type of containers you used to deploy the original stack. For example, set toNEUTRON_DRIVER='"neutron_driver":"ovn",'to use OVN-based containers. EL8_TAGS: The tags of the UBI8 images, for example,EL8_TAGS='"tag":"17.1",'.-
Replace
"17.1",with the tag that you use in your content view.
-
Replace
EL9_TAGS: The tags of the UBI9 images, for example,EL9_TAGS='"tag":"17.1",'.Replace
"17.1",with the tag that you use in your content view.For more information about the
tagparameter, see Container image preparation parameters in Customizing your Red Hat OpenStack Platform deployment.
CONTROL_PLANE_ROLES: The list of control plane roles using the--roleoption, for example,--role ControllerOpenstack, --role Database, --role Messaging, --role Networker, --role CephStorage. To view the list of control plane roles in your environment, run the following command:$ export STACK=<stack> \ $ sudo awk '/tripleo_role_name/ {print "--role " $2}' \ /var/lib/mistral/${STACK}/tripleo-ansible-inventory.yaml \ | grep -vi compute-
Replace
<stack>with the name of your stack.
-
Replace
COMPUTE_ROLES: The list of Compute roles using the--roleoption, for example,--Compute-1. To view the list of Compute roles in your environment, run the following command:$ sudo awk '/tripleo_role_name/ {print "--role " $2}' \ /var/lib/mistral/${STACK}/tripleo-ansible-inventory.yaml \ | grep -i computeCEPH_OVERRIDE: If you deployed Red Hat Ceph Storage, specify the Red Hat Ceph Storage 5 container images. For example:CEPH_OVERRIDE='"ceph_image":"rhceph-5-rhel8","ceph_tag":"<latest>",'Replace
<latest>with the latestceph_tagversion, for example,5-499.The following is an example of the
containers-prepare-parameter.yamlfile configuration:NAMESPACE='"namespace":"registry.redhat.io/rhosp-rhel9",' EL8_NAMESPACE='"namespace":"registry.redhat.io/rhosp-rhel8",' NEUTRON_DRIVER='"neutron_driver":"ovn",' EL8_TAGS='"tag":"17.1",' EL9_TAGS='"tag":"17.1",' CONTROL_PLANE_ROLES="--role Controller" COMPUTE_ROLES="--role Compute1 --role Compute2" CEPH_TAGS='"ceph_tag":"5",'
-
Run the following script to to update the
containers-prepare-parameter.yamlfile:WarningIf you deployed Red Hat Ceph Storage, ensure that the
CEPH_OVERRIDEenvironment variable is set to the correct values before executing the following command. Failure to do so results in issues when upgrading Red Hat Ceph Storage.$ python3 /usr/share/openstack-tripleo-heat-templates/tools/multi-rhel-container-image-prepare.py \ ${COMPUTE_ROLES} \ ${CONTROL_PLANE_ROLES} \ --enable-multi-rhel \ --excludes collectd \ --excludes nova-libvirt \ --minor-override "{${EL8_TAGS}${EL8_NAMESPACE}${CEPH_OVERRIDE}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \ --major-override "{${EL9_TAGS}${NAMESPACE}${CEPH_OVERRIDE}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \ --output-env-file \ /home/stack/containers-prepare-parameter.yamlThe
multi-rhel-container-image-prepare.pyscript supports the following parameters:--output-env-file-
Writes the environment file that contains the default
ContainerImagePreparevalue. --local-push-destination- Triggers an upload to a local registry.
--enable-registry-login-
Enables the flag that allows the system to attempt to log in to a remote registry prior to pulling the containers. Use this flag when
--local-push-destinationis not used and the target systems have network connectivity to remote registries. Do not use this flag for an overcloud that might not have network connectivity to a remote registry. --enable-multi-rhel- Enables multi-rhel.
--excludes- Lists the services to exclude.
--major-override- Lists the override parameters for a major release.
--minor-override- Lists the override parameters for a minor release.
--role- The list of roles.
--role-file-
The
role_data.yamlfile.
-
If you deployed Red Hat Ceph Storage, open the
containers-prepare-parameter.yamlfile to confirm that the Red Hat Ceph Storage 5 container images are specified and that there are no references to Red Hat Ceph Storage 6 container images.
If you have a director-deployed Red Hat Ceph Storage deployment, create a file called
ceph_params.yamland include the following content:parameter_defaults: CephSpecFqdn: true CephConfigPath: "/etc/ceph" CephAnsibleRepo: "rhceph-5-tools-for-rhel-8-x86_64-rpms" DeployedCeph: true GrafanaPlugins: []ImportantDo not remove the
ceph_params.yamlfile after the RHOSP upgrade is complete. This file must be present in director-deployed Red Hat Ceph Storage environments. Additionally, any time you runopenstack overcloud deploy, you must include theceph_params.yamlfile, for example,-e ceph_params.yaml.NoteIf your Red Hat Ceph Storage deployment includes short names, you must set the
CephSpecFqdnparameter tofalse. If set totrue, the inventory generates with both the short names and domain names, causing the Red Hat Ceph Storage upgrade to fail.Create an environment file called
upgrades-environment.yamlin your templates directory and include the following content:parameter_defaults: ExtraConfig: nova::workarounds::disable_compute_service_check_for_ffu: true DnsServers: ["<dns_servers>"] DockerInsecureRegistryAddress: [<undercloud_FQDN>] UpgradeInitCommand: | sudo subscription-manager repos --disable=* if $( grep -q 9.2 /etc/os-release ) then sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-e4s-rpms --enable=rhel-9-for-x86_64-appstream-e4s-rpms --enable=rhel-9-for-x86_64-highavailability-e4s-rpms --enable=openstack-17.1-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-9-x86_64-rpms sudo subscription-manager release --set=9.2 else sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-aus-rpms --enable=rhel-8-for-x86_64-appstream-aus-rpms --enable=rhel-8-for-x86_64-highavailability-aus-rpms --enable=openstack-17.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-8-x86_64-rpms sudo subscription-manager release --set=8.4 fi if $(sudo podman ps | grep -q ceph ) then sudo dnf -y install cephadm fi-
Replace
<dns_servers>with a comma-separated list of your DNS server IP addresses, for example,["10.0.0.36", "10.0.0.37"]. Replace
<undercloud_FQDN>with the fully qualified domain name (FQDN) of the undercloud host, for example,["undercloud-0.ctlplane.redhat.local:8787"].For more information about the upgrade parameters that you can configure in the environment file, see Upgrade parameters.
-
Replace
On the undercloud, create a file called
overcloud_upgrade_prepare.shin your templates directory. You must create this file for each stack in your environment. This file includes the original content of your overcloud deploy file and the environment files that are relevant to your environment. For example:#!/bin/bash openstack overcloud upgrade prepare --yes \ --timeout 460 \ --templates /usr/share/openstack-tripleo-heat-templates \ --ntp-server 192.168.24.1 \ --stack <stack> \ -r /home/stack/roles_data.yaml \ -e /home/stack/templates/internal.yaml \ -e /home/stack/templates/network/network-environment.yaml \ -e /home/stack/templates/inject-trust-anchor.yaml \ -e /home/stack/templates/hostnames.yml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -e /home/stack/templates/nodes_data.yaml \ -e /home/stack/templates/debug.yaml \ -e /home/stack/templates/firstboot.yaml \ -e /home/stack/templates/upgrades-environment.yaml \ -e /home/stack/overcloud-params.yaml \ -e /home/stack/templates/overcloud-network-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/nova-hw-machine-type-upgrade.yaml \ -e /home/stack/skip_rhel_release.yaml \ -e ~/containers-prepare-parameter.yaml \ -e /home/stack/templates/baremetal-deployment.yaml \ -e /home/stack/templates/generated-networks-deployed.yaml \ -e /home/stack/templates/generated-vip-deployed.yaml-
In the original
network-environment.yamlfile (/home/stack/templates/network/network-environment.yaml), remove all the resource_registry resources that point toOS::TripleO::*::Net::SoftwareConfig. In the
overcloud_upgrade_prepare.shfile, include the following options relevant to your environment:-
The environment file (
upgrades-environment.yaml) with the upgrade-specific parameters (-e). -
The environment file (
containers-prepare-parameter.yaml) with your new container image locations (-e). In most cases, this is the same environment file that the undercloud uses. -
The environment file (
skip_rhel_release.yaml) with the release parameters (-e). -
Any custom configuration environment files (
-e) relevant to your deployment. -
If applicable, your custom roles (
roles_data) file by using--roles-file. -
For Ceph deployments, the environment file (
ceph_params.yaml) with the Ceph parameters (-e). -
If applicable, the environment file (
ipa-environment.yaml) with your IPA service (-e). -
If you are using composable networks, the (
network_data) file by using--network-file. -
The files that were generated during overcloud adoption (
networks-deployed.yaml,vip-deployed.yaml,baremetal-deployment.yaml) (-e). These files must be placed last in the overcloud upgrade prepare script. If you use OVS, add the OVS environment files in the following order:
-
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml
-
If you use OVN, add the OVN environment files in the following order:
-
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-dpdk.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-ha.yamlNoteDo not include the
network-isolation.yamlfile in your overcloud deploy file or theovercloud_upgrade_prepare.shfile. Network isolation is defined in thenetwork_data.yamlfile.
-
If you use a custom stack name, pass the name with the
--stackoption.NoteYou must include the
nova-hw-machine-type-upgrade.yamlfile in your templates until all of your RHEL 8 Compute nodes are upgraded to RHEL 9 in the environment. If this file is excluded, an error appears in thenova_compute.login the/var/log/containers/novadirectory. After you upgrade all of your RHEL 8 Compute nodes to RHEL 9, you can remove this file from your configuration and update the stack.
-
The environment file (
In the director-deployed Red Hat Ceph Storage use case, if you enabled the Shared File Systems service (manila) with CephFS through NFS on the deployment that you are upgrading, you must specify an additional environment file at the end of the
overcloud_upgrade_prepare.shscript file. You must add the environment file at the end of the script because it overrides another environment file that is specified earlier in the script:-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yamlIn the external Red Hat Ceph Storage use case, if you enabled the Shared File Systems service (manila) with CephFS through NFS on the deployment that you are upgrading, you must check that the associated environment file in the
overcloud_upgrade_prepare.shscript points to the tripleo-basedceph-nfsrole. If present, remove the following environment file:-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yamlAnd add the following environment file:
-e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml
-
In the original
Run the upgrade preparation script for each stack in your environment:
$ source stackrc $ chmod 755 /home/stack/overcloud_upgrade_prepare.sh $ sh /home/stack/overcloud_upgrade_prepare.sh- Wait until the upgrade preparation completes.
Download the container images:
$ openstack overcloud external-upgrade run --stack <stack> --tags container_image_prepare
8.2. Performing the overcloud adoption and preparation for multi-cell environments Copy linkLink copied to clipboard!
You must perform the following tasks for overcloud adoption:
On each stack, adopt the network and host provisioning configuration exports into the overcloud. The following example shows how to adopt the
virtual-ips.yamlfile to each cell stack, starting with the overcloud stack:Overcloud stack:
$ cp ~/overcloud-deploy/<overcloud>/tripleo-<overcloud>-virtual-ips.yaml ~/ \ $ cd ~/ \ $ openstack overcloud network vip provision \ --debug --stack <overcloud> \ --output /home/stack/templates/generated-<overcloud-stack>-vip-deployed.yaml \ tripleo-<overcloud-stack>-virtual-ips.yamlCell stack 1:
$ cp ~/overcloud-deploy/<stack1>/tripleo-<stack1>-virtual-ips.yaml ~/ \ $ cd ~/ \ $ openstack overcloud network vip provision \ --debug --stack <stack1> \ --output /home/stack/templates/generated-<stack1>-vip-deployed.yaml \ tripleo-<stack1>-virtual-ips.yamlCell stack 2:
$ cp ~/overcloud-deploy/<stack2>/tripleo-<stack2>-virtual-ips.yaml ~/ \ $ cd ~/ \ $ openstack overcloud network vip provision \ --debug --stack <stack2> \ --output /home/stack/templates/generated-<stack2>-vip-deployed.yaml \ tripleo-<stack2>-virtual-ips.yaml
- Define new containers and additional compatibility configuration.
After adoption, you must run the upgrade preparation script on each cell stack, which performs the following tasks:
- Updates the overcloud plan to OpenStack Platform 17.1
- Prepares the nodes for the upgrade
For information about the duration and impact of this upgrade procedure, see Upgrade duration and impact.
If your roles include a large number of nodes, you can accelerate the RHOSP upgrade by splitting existing roles and dividing the nodes between the roles. For more information, see the Red Hat Knowledgebase solution How to split roles during upgrade from RHOSP 16.2 to RHOSP 17.1.
Prerequisites
-
Confirm that all bare-metal provisioned nodes are in the
ACTIVEstate. If any nodes remain in theMAINTENANCEstate, you cannot proceed with the upgrade. For more information about setting the nodes toACTIVE, see Setting bare-metal provisioned nodes to the active state.
Procedure
-
Log in to the undercloud host as the
stackuser. Source the
stackrcundercloud credentials file:$ source ~/stackrcVerify that the following files that were exported during the undercloud upgrade contain the expected configuration for the overcloud upgrade. You can find the following files in the
~/overcloud-deploy/$(<stack>)directory:-
tripleo-<stack>-network-data.yaml -
tripleo-<stack>-virtual-ips.yaml tripleo-<stack>-baremetal-deployment.yaml-
Replace
<stack>with the name of your stack. -
Check that the mappings between the baremetal node UUIDs, hostnames, and IP addresses in the
tripleo-<stack>-baremetal-deployment.yamlfile match your current overcloud. Correct the mappings if required.
-
Replace
WarningYou must address the issues in Jinja2 comments, and then remove all Jinja2 comment blocks, from each nic-config template that is created by automated conversion tools such as
convert_v1_net_data.pyorconvert_heat_nic_config_to_ansible_j2.pyduring the undercloud upgrade. If you do not remove these comment blocks, scaled-out nodes fail to provision, or you can lose control plane networking ifnetwork_config_updateis set totrue.{{# NOTE! Custom parameter {} was hard-coded in ' 'the converted template. To parameterize use the ' '{{role.name}}ExtraGroupVars THT interface and update the ' 'template to use an ansible var. +#}}-
On the main stack, copy the
network-data.yamlfile to the stack user’s home directory and deploy the networks. Repeat this step on each cell stack in your environment:NoteThe
network-data.yamlfile is available only on the overcloud stack. You must copy the file from the overcloud stack to all the other cell stacks.$ cp ~/overcloud-deploy/<overcloud-stack>/tripleo-<overcloud-stack>-network-data.yaml ~/ $ openstack overcloud network provision --debug \ --output /home/stack/templates/generated-<overcloud-stack>-networks-deployed.yaml tripleo-<overcloud-stack>-network-data.yamlFor more information, see Provisioning and deploying your overcloud in Installing and managing Red Hat OpenStack Platform with director.
If your environment has pre-provisioned nodes, complete the following steps in each stack in your environment, starting with the overcloud stack:
Make a backup copy of the
tripleo-<overcloud-stack>-virtual-ips.yamlfile in the stack user’s home directory:$ cp ~/overcloud-deploy/<overcloud-stack>/tripleo-<overcloud-stack>-virtual-ips.yaml ~/ ~/overcloud-deploy/<overcloud-stack>/tripleo-<overcloud-stack>-virtual-ips.yaml.origInclude the following configuration at the end of the
tripleo-<overcloud-stack>-virtual-ips.yamlfile:dns_name: overcloud ip_address: <ctrlplane_virtual_ip>1 name: control_virtual_ip2 network: ctlplane subnet: ctlplane-subnet
On the overcloud stack, copy the
virtual-ips.yamlfile to the stack user’s home directory and provision the network VIPs. Repeat this step on each cell stack in your environment:$ cp ~/overcloud-deploy/<overcloud-stack>/tripleo-<overcloud-stack>-virtual-ips.yaml ~/ $ openstack overcloud network vip provision --debug \ --stack <overcloud-stack> --output \ /home/stack/templates/generated-<overcloud-stack>-vip-deployed.yaml tripleo-<overcloud-stack>-virtual-ips.yamlOn the main stack, copy the
baremetal-deployment.yamlfile to the stack user’s home directory and provision the overcloud nodes. Repeat this step on each cell stack in your environment:$ cp ~/overcloud-deploy/<overcloud-stack>/tripleo-<overcloud-stack>-baremetal-deployment.yaml ~/ $ openstack overcloud node provision --debug --stack <overcloud-stack> \ --output /home/stack/templates/baremetal-<overcloud-stack>-deployment.yaml \ tripleo-<overcloud-stack>-baremetal-deployment.yamlNoteThis is the final step of the overcloud adoption. If your overcloud adoption takes longer than 10 minutes to complete, contact Red Hat Support.
Complete the following steps to prepare the containers:
Back up the
containers-prepare-parameter.yamlfile that you used for the undercloud upgrade:$ cp containers-prepare-parameter.yaml \ containers-prepare-parameter.yaml.origDefine the following environment variables before you run the script to update the
containers-prepare-parameter.yamlfile:-
NAMESPACE: The namespace for the UBI9 images. For example,NAMESPACE='"namespace":"example.redhat.com:5002",' -
EL8_NAMESPACE: The namespace for the UBI8 images. -
NEUTRON_DRIVER: The driver to use and determine which OpenStack Networking (neutron) container to use. Set to the type of containers you used to deploy the original stack. For example, set toNEUTRON_DRIVER='"neutron_driver":"ovn",'to use OVN-based containers. EL8_TAGS: The tags of the UBI8 images, for example,EL8_TAGS='"tag":"17.1",'.-
Replace
"17.1",with the tag that you use in your content view.
-
Replace
EL9_TAGS: The tags of the UBI9 images, for example,EL9_TAGS='"tag":"17.1",'.Replace
"17.1",with the tag that you use in your content view.For more information about the
tagparameter, see Container image preparation parameters in Customizing your Red Hat OpenStack Platform deployment.
CONTROL_PLANE_ROLES: The list of control plane roles using the--roleoption, for example,--role ControllerOpenstack, --role Database, --role Messaging, --role Networker, --role CephStorage. To view the list of control plane roles in your environment, run the following command:$ export STACK=<stack> \ $ sudo awk '/tripleo_role_name/ {print "--role " $2}' \ /var/lib/mistral/${STACK}/tripleo-ansible-inventory.yaml \ | grep -vi compute-
Replace
<stack>with the name of your stack.
-
Replace
COMPUTE_ROLES: The list of Compute roles using the--roleoption, for example,--Compute-1. To view the list of Compute roles in your environment, run the following command:$ sudo awk '/tripleo_role_name/ {print "--role " $2}' \ /var/lib/mistral/${STACK}/tripleo-ansible-inventory.yaml \ | grep -i computeCEPH_OVERRIDE: If you deployed Red Hat Ceph Storage, specify the Red Hat Ceph Storage 5 container images. For example:CEPH_OVERRIDE='"ceph_image":"rhceph-5-rhel8","ceph_tag":"<latest>",'Replace
<latest>with the latestceph_tagversion, for example,5-499.The following is an example of the
containers-prepare-parameter.yamlfile configuration:NAMESPACE='"namespace":"registry.redhat.io/rhosp-rhel9",' EL8_NAMESPACE='"namespace":"registry.redhat.io/rhosp-rhel8",' NEUTRON_DRIVER='"neutron_driver":"ovn",' EL8_TAGS='"tag":"17.1",' EL9_TAGS='"tag":"17.1",' CONTROL_PLANE_ROLES="--role Controller" COMPUTE_ROLES="--role Compute1 --role Compute2" CEPH_TAGS='"ceph_tag":"5",'
-
Run the following script to to update the
containers-prepare-parameter.yamlfile:WarningIf you deployed Red Hat Ceph Storage, ensure that the
CEPH_OVERRIDEenvironment variable is set to the correct values before executing the following command. Failure to do so results in issues when upgrading Red Hat Ceph Storage.$ python3 /usr/share/openstack-tripleo-heat-templates/tools/multi-rhel-container-image-prepare.py \ ${COMPUTE_ROLES} \ ${CONTROL_PLANE_ROLES} \ --enable-multi-rhel \ --excludes collectd \ --excludes nova-libvirt \ --minor-override "{${EL8_TAGS}${EL8_NAMESPACE}${CEPH_OVERRIDE}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \ --major-override "{${EL9_TAGS}${NAMESPACE}${CEPH_OVERRIDE}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \ --output-env-file \ /home/stack/containers-prepare-parameter.yamlThe
multi-rhel-container-image-prepare.pyscript supports the following parameters:--output-env-file-
Writes the environment file that contains the default
ContainerImagePreparevalue. --local-push-destination- Triggers an upload to a local registry.
--enable-registry-login-
Enables the flag that allows the system to attempt to log in to a remote registry prior to pulling the containers. Use this flag when
--local-push-destinationis not used and the target systems have network connectivity to remote registries. Do not use this flag for an overcloud that might not have network connectivity to a remote registry. --enable-multi-rhel- Enables multi-rhel.
--excludes- Lists the services to exclude.
--major-override- Lists the override parameters for a major release.
--minor-override- Lists the override parameters for a minor release.
--role- The list of roles.
--role-file-
The
role_data.yamlfile.
-
If you deployed Red Hat Ceph Storage, open the
containers-prepare-parameter.yamlfile to confirm that the Red Hat Ceph Storage 5 container images are specified and that there are no references to Red Hat Ceph Storage 6 container images.
If you have a director-deployed Red Hat Ceph Storage deployment, create a file called
ceph_params.yamland include the following content:parameter_defaults: CephSpecFqdn: true CephConfigPath: "/etc/ceph" CephAnsibleRepo: "rhceph-5-tools-for-rhel-8-x86_64-rpms" DeployedCeph: true GrafanaPlugins: []ImportantDo not remove the
ceph_params.yamlfile after the RHOSP upgrade is complete. This file must be present in director-deployed Red Hat Ceph Storage environments. Additionally, any time you runopenstack overcloud deploy, you must include theceph_params.yamlfile, for example,-e ceph_params.yaml.NoteIf your Red Hat Ceph Storage deployment includes short names, you must set the
CephSpecFqdnparameter tofalse. If set totrue, the inventory generates with both the short names and domain names, causing the Red Hat Ceph Storage upgrade to fail.Create an environment file called
upgrades-environment.yamlin your templates directory and include the following content:parameter_defaults: ExtraConfig: nova::workarounds::disable_compute_service_check_for_ffu: true DnsServers: ["<dns_servers>"] DockerInsecureRegistryAddress: [<undercloud_FQDN>] UpgradeInitCommand: | sudo subscription-manager repos --disable=* if $( grep -q 9.2 /etc/os-release ) then sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-e4s-rpms --enable=rhel-9-for-x86_64-appstream-e4s-rpms --enable=rhel-9-for-x86_64-highavailability-e4s-rpms --enable=openstack-17.1-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-9-x86_64-rpms sudo subscription-manager release --set=9.2 else sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-aus-rpms --enable=rhel-8-for-x86_64-appstream-aus-rpms --enable=rhel-8-for-x86_64-highavailability-aus-rpms --enable=openstack-17.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-8-x86_64-rpms sudo subscription-manager release --set=8.4 fi if $(sudo podman ps | grep -q ceph ) then sudo dnf -y install cephadm fi-
Replace
<dns_servers>with a comma-separated list of your DNS server IP addresses, for example,["10.0.0.36", "10.0.0.37"]. Replace
<undercloud_FQDN>with the fully qualified domain name (FQDN) of the undercloud host, for example,["undercloud-0.ctlplane.redhat.local:8787"].For more information about the upgrade parameters that you can configure in the environment file, see Upgrade parameters.
-
Replace
On the undercloud, create a file called
overcloud_upgrade_prepare.shin your templates directory. You must create this file for each stack in your environment, starting with the overcloud stack. This file includes the original content of your overcloud deploy file and the environment files that are relevant to each cell stack. For example:#!/bin/bash openstack overcloud upgrade prepare --yes \ --timeout 460 \ --templates /usr/share/openstack-tripleo-heat-templates \ --ntp-server 192.168.24.1 \ --stack <overcloud-stack> \ -r /home/stack/roles_data.yaml \ -e /home/stack/templates/internal.yaml \ -e /home/stack/templates/network/network-environment.yaml \ -e /home/stack/templates/inject-trust-anchor.yaml \ -e /home/stack/templates/hostnames.yml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -e /home/stack/templates/nodes_data.yaml \ -e /home/stack/templates/debug.yaml \ -e /home/stack/templates/firstboot.yaml \ -e /home/stack/templates/upgrades-environment.yaml \ -e /home/stack/overcloud-params.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/nova-hw-machine-type-upgrade.yaml \ -e /home/stack/skip_rhel_release.yaml \ -e ~/containers-prepare-parameter.yaml \ -e /home/stack/templates/baremetal-<overcloud-stack>-deployment.yaml \ -e /home/stack/templates/generated-<overcloud-stack>-networks-deployed.yaml \ -e /home/stack/templates/generated-<overcloud-stack>-vip-deployed.yaml-
In the original
network-environment.yamlfile (/home/stack/templates/network/network-environment.yaml), remove all the resource_registry resources that point toOS::TripleO::*::Net::SoftwareConfig. In the
overcloud_upgrade_prepare.shfile, include the following options relevant to your environment:-
The environment file (
upgrades-environment.yaml) with the upgrade-specific parameters (-e). -
The environment file (
containers-prepare-parameter.yaml) with your new container image locations (-e). In most cases, this is the same environment file that the undercloud uses. -
The
default_cell_export.yamlfile that you exported from the default cell in the overcloud stack. You must add this file to all of theovercloud_upgrade_prepare.shfiles for each cell stack, except for the overcloud stack. -
The environment file (
skip_rhel_release.yaml) with the release parameters (-e). -
Any custom configuration environment files (
-e) relevant to your deployment. -
If applicable, your custom roles (
roles_data) file by using--roles-file. -
For Ceph deployments, the environment file (
ceph_params.yaml) with the Ceph parameters (-e). -
If applicable, the environment file (
ipa-environment.yaml) with your IPA service (-e). -
If you are using composable networks, the (
network_data) file by using--network-file. -
The files that were generated during overcloud adoption (
networks-deployed.yaml,vip-deployed.yaml,baremetal-deployment.yaml) (-e). These files must be placed last in the overcloud upgrade prepare script. If you use OVS, add the OVS environment files in the following order:
-
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml
-
If you use OVN, add the OVN environment files in the following order:
-
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-dpdk.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-ha.yamlNoteDo not include the
network-isolation.yamlfile in your overcloud deploy file or theovercloud_upgrade_prepare.shfile. Network isolation is defined in thenetwork_data.yamlfile.
-
If you use a custom stack name, pass the name with the
--stackoption.NoteYou must include the
nova-hw-machine-type-upgrade.yamlfile in your templates until all of your RHEL 8 Compute nodes are upgraded to RHEL 9 in the environment. If this file is excluded, an error appears in thenova_compute.login the/var/log/containers/novadirectory. After you upgrade all of your RHEL 8 Compute nodes to RHEL 9, you can remove this file from your configuration and update the stack.
-
The environment file (
In the director-deployed Red Hat Ceph Storage use case, if you enabled the Shared File Systems service (manila) with CephFS through NFS on the deployment that you are upgrading, you must specify an additional environment file at the end of the
overcloud_upgrade_prepare.shscript file. You must add the environment file at the end of the script because it overrides another environment file that is specified earlier in the script:-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yamlIn the external Red Hat Ceph Storage use case, if you enabled the Shared File Systems service (manila) with CephFS through NFS on the deployment that you are upgrading, you must check that the associated environment file in the
overcloud_upgrade_prepare.shscript points to the tripleo-basedceph-nfsrole. If present, remove the following environment file:-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yamlAnd add the following environment file:
-e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml
-
In the original
Run the upgrade preparation script on the overcloud stack:
$ source stackrc $ chmod 755 /home/stack/overcloud_upgrade_prepare.sh $ sh /home/stack/overcloud_upgrade_prepare.shWait until the upgrade preparation completes.
Export the cell configuration and password information from the default cell in the overcloud stack to a new common environment file for the multi-cell deployment. You must include the
/home/stack/common/default_cell_export.yamlfile and all of the environment files that are relevant to your environment in the script for each cell:(undercloud) $ openstack overcloud cell export --control-plane-stack overcloud \ -f --output-file common/default_cell_export.yaml \ --working-dir /home/stack/overcloud-deploy/overcloud/If you have a DCN environment, the generated
cell_export.yamlfile is incomplete. To get the correct file, complete the following steps:Source the
stackrcundercloud credentials file:$ source ~/stackrcForce the necessary data to be generated into the stack’s
overcloud-deploydirectory:$ openstack overcloud upgrade run --yes --limit allovercloud,undercloud --stack overcloud --playbook overcloud/upgrade_steps_playbook.yaml --skip-tags upgrade_stepsRe-export the overcloud stack to to get the updated
cell_export.yamlfile to use in the overcloud upgrade prepare script:$ openstack overcloud cell export --control-plane-stack overcloud --force-overwrite --working-dir overcloud-deploy/overcloud --output-file overcloud-deploy/overcloud/overcloud-cell-export.yaml
Run the upgrade preparation script on each cell stack. For example:
$ source stackrc $ chmod 755 /home/stack/<stack1>-overcloud_upgrade_prepare.sh $ sh /home/stack/<stack1>-overcloud_upgrade_prepare.shWait until the upgrade preparation completes.
Download the container images for each cell stack, starting with the overcloud stack:
$ openstack overcloud external-upgrade run --stack <stack> --tags container_image_prepare