이 콘텐츠는 선택한 언어로 제공되지 않습니다.

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

  1. Log in to your undercloud as the stack user.
  2. Disable all default repositories, and enable the required Red Hat Enterprise Linux (RHEL) repositories:

    [stack@director ~]$ sudo subscription-manager repos --disable=*
    [stack@director ~]$ 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
    Copy to Clipboard Toggle word wrap
  3. Switch the container-tools module version to RHEL 8 on all nodes:

    [stack@director ~]$ sudo dnf -y module switch-to container-tools:rhel8
    Copy to Clipboard Toggle word wrap
  4. Install the command line tools for director installation and configuration:

    [stack@director ~]$ sudo dnf install -y python3-tripleoclient
    Copy to Clipboard Toggle word wrap

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

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

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  3. 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
    Copy to Clipboard Toggle word wrap
    • Replace <stack> with the name of the stack.
  4. Adjust the permissions of the /var/lib/mistral/.ssh directory:

    $ sudo chmod +x /var/lib/mistral/.ssh/
    Copy to Clipboard Toggle word wrap
  5. Install the packages for validation:

    $ sudo dnf -y update openstack-tripleo-validations python3-validations-libs validations-common
    Copy to Clipboard Toggle word wrap
  6. 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
    Copy to Clipboard Toggle word wrap
  7. Run the validation:

    $ validation run -i inventory.yaml --group pre-upgrade
    Copy to Clipboard Toggle word wrap
  8. Review the script output to determine which validations succeed and fail:

    === Running validation: "check-ftype" ===
    
    Success! The validation passed for all hosts:
    * undercloud
    Copy to Clipboard Toggle word wrap
  9. Remove the inventory.yaml file:

    $ -rm inventory.yaml
    Copy to Clipboard Toggle word wrap

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.

Note

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

  1. Log in to the undercloud host as the stack user.
  2. Optional: Back up the 16.2 containers-prepare-parameter.yaml file:

    $ cp containers-prepare-parameter.yaml \
      containers-prepare-parameter.yaml.orig
    Copy to Clipboard Toggle word wrap
  3. Generate the default container image preparation file:

    $ openstack tripleo container image prepare default \
      --local-push-destination \
      --output-env-file containers-prepare-parameter.yaml
    Copy to Clipboard Toggle word wrap

    This command includes the following additional options:

    • --local-push-destination sets 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-file is 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 is containers-prepare-parameter.yaml.

      Note

      You can use the same containers-prepare-parameter.yaml file to define a container image source for both the undercloud and the overcloud.

  4. Modify the containers-prepare-parameter.yaml to suit your requirements. For more information about container image parameters, see Container image preparation parameters.
  5. If your deployment includes Red Hat Ceph Storage, update the Red Hat Ceph Storage container image parameters in the containers-prepare-parameter.yaml file for the version of Red Hat Ceph Storage that your deployment uses:

    ceph_namespace: registry.redhat.io/rhceph
    ceph_image: <ceph_image_file>
    ceph_tag: latest
    ceph_grafana_image: <grafana_image_file>
    ceph_grafana_namespace: registry.redhat.io/rhceph
    ceph_grafana_tag: latest
    Copy to Clipboard Toggle word wrap
    • 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> with rhceph-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, use rhceph-6-rhel9.
    • 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> with rhceph-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, use rhceph-6-dashboard-rhel9.

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 tag to 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_label to 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.

parameter_defaults:
  ContainerImagePrepare:
  - set:
      ...
      tag: 17.1
      ...
Copy to Clipboard Toggle word wrap

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.

parameter_defaults:
  ContainerImagePrepare:
  - set:
      ...
      tag: 17.1.2
      ...
Copy to Clipboard Toggle word wrap

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.

Note

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.

parameter_defaults:
  ContainerImagePrepare:
  - set:
      ...
      # tag: 17.1
      ...
    tag_from_label: '{version}-{release}'
Copy to Clipboard Toggle word wrap

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",
    ...
  }
Copy to Clipboard Toggle word wrap

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.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password
Copy to Clipboard Toggle word wrap

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:

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  - push_destination: true
    set:
      namespace: registry.internalsite.com/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
    registry.internalsite.com:
      myuser2: '0th3rp@55w0rd!'
    '192.0.2.1:8787':
      myuser3: '@n0th3rp@55w0rd!'
Copy to Clipboard Toggle word wrap
Important

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.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: true
Copy to Clipboard Toggle word wrap

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.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: false
Copy to Clipboard Toggle word wrap

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.

Note

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

  1. Log in to your undercloud host as the stack user.
  2. Create a file called skip_rhel_release.yaml and set the SkipRhelEnforcement parameter to true:

    parameter_defaults:
      SkipRhelEnforcement: true
    Copy to Clipboard Toggle word wrap
  3. Open the undercloud.conf file, and add the container_images_file parameter to the DEFAULT section in the file:

    container_images_file = /home/stack/containers-prepare-parameter.yaml
    Copy to Clipboard Toggle word wrap
    • The container_images_file parameter defines the location of the containers-prepare-parameter.yaml environment file so that director pulls container images for the undercloud from the correct location.
  4. Add the custom_env_files parameter to the DEFAULT section in the undercloud.conf file. The custom_env_files parameter defines the location of the skip_rhel_release.yaml file that is required for the upgrade:

    custom_env_files = /home/stack/skip_rhel_release.yaml
    Copy to Clipboard Toggle word wrap
    • Add any additional custom environment files to the custom_env_files parameter, 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
      Copy to Clipboard Toggle word wrap
  5. Check all other parameters in the file for any changes.
  6. 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

  1. Confirm that the tripleo_mysql.service is running:

    $ systemctl status tripleo_mysql
    Copy to Clipboard Toggle word wrap

    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)
    Copy to Clipboard Toggle word wrap
  2. If the service is not running, start the service:

    $ sudo systemctl start tripleo_mysql
    Copy to Clipboard Toggle word wrap
  3. Launch the director configuration script to upgrade director:

    $ openstack undercloud upgrade
    Copy to Clipboard Toggle word wrap

    The director configuration script upgrades director packages and configures director services to match the settings in the undercloud.conf file. This script takes several minutes to complete.

    Note

    The director configuration script prompts for confirmation before proceeding. Bypass this confirmation by using the -y option:

    $ openstack undercloud upgrade -y
    Copy to Clipboard Toggle word wrap

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.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat