이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 5. Upgrading the undercloud
Upgrade the undercloud to Red Hat OpenStack Platform 17.1. The undercloud upgrade uses the running Red Hat OpenStack Platform 16.2 undercloud. The upgrade process exports heat stacks to files, and converts heat to ephemeral heat while upgrading the rest of the services on your nodes.
For information about the duration and impact of this upgrade procedure, see Upgrade duration and impact.
5.1. Enabling repositories for the undercloud 링크 복사링크가 클립보드에 복사되었습니다!
Enable the repositories that are required for the undercloud, and update the system packages to the latest versions.
Procedure
-
Log in to your undercloud as the
stackuser. Disable all default repositories, and enable the required Red Hat Enterprise Linux (RHEL) repositories:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Switch the
container-toolsmodule version to RHEL 8 on all nodes:sudo dnf -y module switch-to container-tools:rhel8
[stack@director ~]$ sudo dnf -y module switch-to container-tools:rhel8Copy to Clipboard Copied! Toggle word wrap Toggle overflow Install the command line tools for director installation and configuration:
sudo dnf install -y python3-tripleoclient
[stack@director ~]$ sudo dnf install -y python3-tripleoclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. Validating RHOSP before the upgrade 링크 복사링크가 클립보드에 복사되었습니다!
Before you upgrade to Red Hat OpenStack Platform (RHOSP) 17.1, validate your undercloud and overcloud with the tripleo-validations playbooks. In RHOSP 16.2, you run these playbooks through the OpenStack Workflow Service (mistral).
For more information about the validation framework, see Using the validation framework in Customizing your Red Hat OpenStack Platform deployment.
Procedure
-
Log in to the undercloud host as the
stackuser. Source the
stackrcundercloud credentials file:source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Confirm that you can ping the overcloud nodes:
tripleo-ansible-inventory --static-yaml-inventory ~/inventory.yaml --stack <stack> --ansible_ssh_user heat-admin ansible -i ~/inventory.yaml all -m ping
$ tripleo-ansible-inventory --static-yaml-inventory ~/inventory.yaml --stack <stack> --ansible_ssh_user heat-admin $ ansible -i ~/inventory.yaml all -m pingCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Replace
<stack>with the name of the stack.
-
Replace
Adjust the permissions of the
/var/lib/mistral/.sshdirectory:sudo chmod +x /var/lib/mistral/.ssh/
$ sudo chmod +x /var/lib/mistral/.ssh/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Install the packages for validation:
sudo dnf -y update openstack-tripleo-validations python3-validations-libs validations-common
$ sudo dnf -y update openstack-tripleo-validations python3-validations-libs validations-commonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy the inventory from mistral:
sudo chown stack:stack /var/lib/mistral/.ssh/tripleo-admin-rsa sudo cat /var/lib/mistral/<stack>/tripleo-ansible-inventory.yaml > inventory.yaml
$ sudo chown stack:stack /var/lib/mistral/.ssh/tripleo-admin-rsa $ sudo cat /var/lib/mistral/<stack>/tripleo-ansible-inventory.yaml > inventory.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the validation:
validation run -i inventory.yaml --group pre-upgrade
$ validation run -i inventory.yaml --group pre-upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Review the script output to determine which validations succeed and fail:
=== Running validation: "check-ftype" === Success! The validation passed for all hosts: * undercloud
=== Running validation: "check-ftype" === Success! The validation passed for all hosts: * undercloudCopy to Clipboard Copied! Toggle word wrap Toggle overflow Remove the
inventory.yamlfile:-rm inventory.yaml
$ -rm inventory.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Preparing container images 링크 복사링크가 클립보드에 복사되었습니다!
The undercloud installation requires an environment file to determine where to obtain container images and how to store them. Generate and customize the environment file that you can use to prepare your container images.
If you need to configure specific container image versions for your undercloud, you must pin the images to a specific version. For more information, see Pinning container images for the undercloud.
Procedure
-
Log in to the undercloud host as the
stackuser. Optional: Back up the 16.2
containers-prepare-parameter.yamlfile:cp containers-prepare-parameter.yaml \ containers-prepare-parameter.yaml.orig
$ cp containers-prepare-parameter.yaml \ containers-prepare-parameter.yaml.origCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate the default container image preparation file:
openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter.yaml
$ openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command includes the following additional options:
-
--local-push-destinationsets the registry on the undercloud as the location for container images. This means that director pulls the necessary images from the Red Hat Container Catalog and pushes them to the registry on the undercloud. Director uses this registry as the container image source. To pull directly from the Red Hat Container Catalog, omit this option. --output-env-fileis an environment file name. The contents of this file include the parameters for preparing your container images. In this case, the name of the file iscontainers-prepare-parameter.yaml.NoteYou can use the same
containers-prepare-parameter.yamlfile to define a container image source for both the undercloud and the overcloud.
-
-
Modify the
containers-prepare-parameter.yamlto suit your requirements. For more information about container image parameters, see Container image preparation parameters. If your deployment includes Red Hat Ceph Storage, update the Red Hat Ceph Storage container image parameters in the
containers-prepare-parameter.yamlfile for the version of Red Hat Ceph Storage that your deployment uses:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<ceph_image_file>with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:-
If you use director-deployed Red Hat Ceph Storage, replace
<ceph_image_file>withrhceph-5-rhel8. -
If you use external Red Hat Ceph Storage, replace
<ceph_image_file>with the same Ceph image that your Red Hat Ceph Storage environment uses. For example, for a Red Hat Ceph Storage 6 image, userhceph-6-rhel9.
-
If you use director-deployed Red Hat Ceph Storage, replace
Replace
<grafana_image_file>with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:-
If you use director-deployed Red Hat Ceph Storage, replace
<grafana_image_file>withrhceph-5-dashboard-rhel8. -
If you use external Red Hat Ceph Storage, replace
<grafana_image_file>with the same Ceph image that your Red Hat Ceph Storage environment uses. For example, for a Red Hat Ceph Storage 6 image, userhceph-6-dashboard-rhel9.
-
If you use director-deployed Red Hat Ceph Storage, replace
5.4. Guidelines for container image tagging 링크 복사링크가 클립보드에 복사되었습니다!
When you prepare image containers in your containers-prepare-parameter.yaml file, you use parameters to determine which container image director pulls when updating your environment, as described in Container image preparation parameters. The Red Hat Container Registry uses a specific version format to tag all Red Hat OpenStack Platform container images. This format follows the label metadata for each container, which is version-release:
- version
- Corresponds to a major and minor version of RHOSP. These versions act as streams that contain one or more releases.
- release
- Corresponds to a release of a specific container image version within a version stream.
For example, if the latest version of RHOSP is 17.1.0 and the release for the container image is 5.161, then the resulting tag for the container image is 17.1.0-5.161.
Major and minor version tags
The Red Hat Container Registry also uses a set of major and minor version tags that link to the latest release for that container image version. For example, both 17.1 and 17.1.0 link to the latest release in the 17.1.0 container stream. If a new minor release of 17.1 occurs, the 17.1 tag links to the latest release for the new minor release stream while the 17.1.0 tag continues to link to the latest release in the 17.1.0 stream.
Setting the tag and tag_from_label parameters
In your containers-prepare-parameter.yaml file, the ContainerImagePrepare parameter contains tag and tag_from_label sub-parameters. You can use tag or tag_from_label to determine which container image to download:
tag-
director uses
tagto pull an image only based on major or minor version tags, which the Red Hat Container Registry links to the latest image release within a version stream. tag_from_label-
director uses
tag_from_labelto perform a metadata inspection of each container image and generates a tag to pull the corresponding image.
The tag parameter always takes precedence over the tag_from_label parameter. To use tag_from_label, omit the tag parameter from your container preparation configuration.
Setting the tag parameter
The default value for tag is the major version for your RHOSP version, for example 17.1. This value always corresponds to the latest minor version and release.
To change to a specific minor version for RHOSP container images, set the tag to a minor version. For example, to change to 17.1.2, set tag to 17.1.2.
When you set tag, director always downloads the latest container image release for the version set in tag during installation and updates, including stack updates.
If you are doing a stack update, you might not want the latest container image but the container image that matches your environment. In this case, omit the tag parameter from your container preparation configuration and specify tag_from_label only. The tag_from_label parameter uses the installed RHOSP version to determine the value for the tag to use as part of the update process.
Setting the tag_from_label parameter
If you do not set tag, director uses the value of tag_from_label in conjunction with the latest major version.
The tag_from_label parameter generates the tag from the label metadata of the latest container image release it inspects from the Red Hat Container Registry. For example, the labels for a certain container might use the following version and release metadata:
"Labels": {
"release": "5.161",
"version": "17.1.0",
...
}
"Labels": {
"release": "5.161",
"version": "17.1.0",
...
}
The default value for tag_from_label is {version}-{release}, which corresponds to the version and release metadata labels for each container image. For example, if a container image has 17.1.0 set for version and 5.161 set for release, the resulting tag for the container image is 17.1.0-5.161.
5.5. Obtaining container images from private registries 링크 복사링크가 클립보드에 복사되었습니다!
The registry.redhat.io registry requires authentication to access and pull images. To authenticate with registry.redhat.io and other private registries, include the ContainerImageRegistryCredentials and ContainerImageRegistryLogin parameters in your containers-prepare-parameter.yaml file.
ContainerImageRegistryCredentials
Some container image registries require authentication to access images. In this situation, use the ContainerImageRegistryCredentials parameter in your containers-prepare-parameter.yaml environment file. The ContainerImageRegistryCredentials parameter uses a set of keys based on the private registry URL. Each private registry URL uses its own key and value pair to define the username (key) and password (value). This provides a method to specify credentials for multiple private registries.
In the example, replace my_username and my_password with your authentication credentials. Instead of using your individual user credentials, Red Hat recommends creating a registry service account and using those credentials to access registry.redhat.io content.
To specify authentication details for multiple registries, set multiple key-pair values for each registry in ContainerImageRegistryCredentials:
The default ContainerImagePrepare parameter pulls container images from registry.redhat.io, which requires authentication.
For more information, see Red Hat Container Registry Authentication.
ContainerImageRegistryLogin
The ContainerImageRegistryLogin parameter is used to control whether an overcloud node system needs to log in to the remote registry to fetch the container images. This situation occurs when you want the overcloud nodes to pull images directly, rather than use the undercloud to host images.
You must set ContainerImageRegistryLogin to true if push_destination is set to false or not used for a given strategy.
However, if the overcloud nodes do not have network connectivity to the registry hosts defined in ContainerImageRegistryCredentials and you set ContainerImageRegistryLogin to true, the deployment might fail when trying to perform a login. If the overcloud nodes do not have network connectivity to the registry hosts defined in the ContainerImageRegistryCredentials, set push_destination to true and ContainerImageRegistryLogin to false so that the overcloud nodes pull images from the undercloud.
5.6. Updating the undercloud.conf file 링크 복사링크가 클립보드에 복사되었습니다!
You can continue using the original undercloud.conf file from your Red Hat OpenStack Platform 16.2 environment, but you must modify the file to retain compatibility with Red Hat OpenStack Platform 17.1. For more information about parameters for configuring the undercloud.conf file, see Undercloud configuration parameters in Installing and managing Red Hat OpenStack Platform with director.
If your original undercloud.conf file includes the CertmongerKerberosRealm parameter in the /home/stack/custom-kerberos-params.yaml file, you must replace the CertmongerKerberosRealm parameter with the HAProxyCertificatePrincipal parameter. The CertmongerKerberosRealm parameter causes the undercloud upgrade to fail.
Procedure
-
Log in to your undercloud host as the
stackuser. Create a file called
skip_rhel_release.yamland set theSkipRhelEnforcementparameter totrue:parameter_defaults: SkipRhelEnforcement: true
parameter_defaults: SkipRhelEnforcement: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the
undercloud.conffile, and add thecontainer_images_fileparameter to theDEFAULTsection in the file:container_images_file = /home/stack/containers-prepare-parameter.yaml
container_images_file = /home/stack/containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
The
container_images_fileparameter defines the location of thecontainers-prepare-parameter.yamlenvironment file so that director pulls container images for the undercloud from the correct location.
-
The
Add the
custom_env_filesparameter to theDEFAULTsection in theundercloud.conffile. Thecustom_env_filesparameter defines the location of theskip_rhel_release.yamlfile that is required for the upgrade:custom_env_files = /home/stack/skip_rhel_release.yaml
custom_env_files = /home/stack/skip_rhel_release.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add any additional custom environment files to the
custom_env_filesparameter, separated by a comma. Ensure that any existing files in the parameter are included in the list. For example:custom_env_files = /home/stack/custom-undercloud-params.yaml,/home/stack/skip_rhel_release.yaml
custom_env_files = /home/stack/custom-undercloud-params.yaml,/home/stack/skip_rhel_release.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Check all other parameters in the file for any changes.
- Save the file.
5.7. Running the director upgrade 링크 복사링크가 클립보드에 복사되었습니다!
Upgrade director on the undercloud.
Prerequisites
- Check the configuration of your deployment files for any issues. For more information, see Deployment file configuration.
- If your network configuration templates include certain functions, ensure that you manually convert your NIC templates to Jinja2 Ansible format. For a list of those functions and a link to the manual procedure, see Network configuration file conversion.
Procedure
Confirm that the
tripleo_mysql.serviceis running:systemctl status tripleo_mysql
$ systemctl status tripleo_mysqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Sample output
The command shows the following output if the service is not running:
tripleo_mysql.service - mysql container Loaded: loaded (/etc/systemd/system/tripleo_mysql.service; enabled; vendor preset: disabled) Active: inactive (dead)
tripleo_mysql.service - mysql container Loaded: loaded (/etc/systemd/system/tripleo_mysql.service; enabled; vendor preset: disabled) Active: inactive (dead)Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the service is not running, start the service:
sudo systemctl start tripleo_mysql
$ sudo systemctl start tripleo_mysqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Launch the director configuration script to upgrade director:
openstack undercloud upgrade
$ openstack undercloud upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow The director configuration script upgrades director packages and configures director services to match the settings in the
undercloud.conffile. This script takes several minutes to complete.NoteThe director configuration script prompts for confirmation before proceeding. Bypass this confirmation by using the
-yoption:openstack undercloud upgrade -y
$ openstack undercloud upgrade -yCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Next steps
- Check that the container version is 17.1 and that the adoption files were generated for all of your stacks. For more information, see the Post-Upgrade Checks section in the Red Hat Knowledgebase article Undercloud Upgrade Checks.