Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 1. About the Red Hat OpenStack Platform framework for upgrades

The Red Hat OpenStack Platform (RHOSP) framework for upgrades is a workflow to upgrade your RHOSP environment from one long life version to the next long life version. This workflow is an in-place solution and the upgrade occurs within your existing environment.

Important

Before you begin the upgrade, open a proactive support case at least 10 days before your planned maintenance window. Proactive support cases provide an opportunity for Red Hat Support to review your templates and process, and potentially avoid any issues during the upgrade. For more information about opening proactive support cases, see the Red Hat Knowledgebase article How to open a proactive case for a planned activity on Red Hat OpenStack Platform?.

1.1. High-level changes in Red Hat OpenStack Platform 17.1
Link kopieren

The following high-level changes occur during the upgrade to Red Hat OpenStack Platform (RHOSP) 17.1:

  • The RHOSP upgrade and the operating system upgrade are separated into two distinct phases. You upgrade RHOSP first, then you upgrade the operating system.
  • You can upgrade a portion of your Compute nodes to RHEL 9.2 while the rest of your Compute nodes remain on RHEL 8.4. This is called a Multi-RHEL environment.

  • With an upgrade to Red Hat Ceph Storage 5, cephadm now manages Red Hat Ceph Storage. Previous versions of Red Hat Ceph Storage were managed by ceph-ansible. You can upgrade your Red Hat Ceph Storage nodes from version 5 to version 6 after the upgrade to RHOSP 17.1 is complete. Otherwise, Red Hat Ceph Storage nodes can remain on version 5 with RHOSP 17.1 until the end of the Red Hat Ceph Storage 5 lifecycle. To upgrade from Red Hat Ceph Storage version 5 to version 6, begin with one of the following procedures for your environment:

  • By default, the RHOSP overcloud uses Open Virtual Network (OVN) as the default ML2 mechanism driver in versions 16.2 and 17.1.

    If your RHOSP 16.2 deployment uses the OVS mechanism driver, you must upgrade to 17.1 with the OVS mechanism driver. Do not attempt to change the mechanism driver during the upgrade. After the upgrade, you can migrate from the OVS to the OVN mechanism driver. See Migrating to the OVN mechanism driver.

  • In ML2/OVN deployments, you can enable egress minimum and maximum bandwidth policies for hardware offloaded ports.

    For more information, see Configuring the Networking service for QoS policies in Configuring Red Hat OpenStack Platform networking.

  • The undercloud and overcloud both run on Red Hat Enterprise Linux 9.

1.2. Familiarize yourself with Red Hat OpenStack Platform 17.1
Link kopieren

Before you perform an upgrade, familiarize yourself with Red Hat OpenStack Platform 17.1 to help you understand the resulting environment and any potential version-to-version changes that might affect your upgrade. To familiarize yourself with Red Hat OpenStack Platform 17.1, follow these suggestions:

  • Read the release notes for all versions across the upgrade path and identify any potential aspects that require planning:

    • Components that contain new features
    • Known issues

    Open the release notes for each version using these links:

  • Read the Installing and managing Red Hat OpenStack Platform with director guide for version 17.1 and familiarize yourself with any new requirements and processes in this guide.

  • Familiarize yourself with the structure and format of heat templates, and the architecture of custom roles and composable services.

  • Install a proof-of-concept Red Hat OpenStack Platform 17.1 undercloud and overcloud. Develop hands-on experience of the target OpenStack Platform version and investigate potential differences between the target version and your current version.

1.3. Changes in Red Hat Enterprise Linux 9
Link kopieren

The Red Hat OpenStack Platform (RHOSP) 17.1 uses Red Hat Enterprise Linux (RHEL) 9.2 as the base operating system. As a part of the upgrade process, you will upgrade the base operating system of nodes to RHEL 9.2.

Before beginning the upgrade, review the following information to familiarize yourself with RHEL 9:

1.4. Leapp upgrade usage in Red Hat OpenStack Platform
Link kopieren

The long-life Red Hat OpenStack Platform upgrade requires a base operating system upgrade from Red Hat Enterprise Linux (RHEL) 8.4 to RHEL 9.2. The upgrade process uses the Leapp utility to perform the upgrade to RHEL 9.2. However, some aspects of the Leapp upgrade are customized to ensure that you are upgrading specifically from RHEL 8.4 to RHEL 9.2. To upgrade your operating system to RHEL 9.2, see Performing the undercloud system upgrade.

Limitations

For information on potential limitations that might affect your upgrade, see the following sections from the Upgrading from RHEL 8 to RHEL 9 guide:

If any known limitations affect your environment, seek advice from the Red Hat Technical Support Team.

Troubleshooting

For information about troubleshooting potential Leapp issues, see Troubleshooting in Upgrading from RHEL 8 to RHEL 9.

1.5. Guidelines for planning the upgrade
Link kopieren

When planning to upgrade a Red Hat OpenStack Platform (RHOSP) environment from 16.2 to 17.1, consider the scope of the change. A RHOSP upgrade is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, storage interfaces, and so on affect the upgrade process and can cause changes in behavior during the upgrade.

Review the following guidelines to adequately plan for the upgrade and increase the chance that you complete the upgrade successfully:

Important

All commands in the upgrade documentation are examples. Do not copy and paste the commands without understanding what the commands do.

  • Use the following documentation to identify any parameters in your templates that are deprecated. You must update these parameters in the templates you plan to use during the upgrade:

  • To minimize the risk of an upgrade failure, reduce the number of environmental differences between the staging environment and the production sites.
  • If the staging environment is not representative of the production sites or if a staging environment is not available, you must plan to include contingency time in case the upgrade fails.

  • Review your custom RHOSP service configuration at every major release.

    • Every major release upgrades through multiple OpenStack releases.
    • Each major release might deprecate configuration options or change the format of the configuration.
  • Prepare a Method of Procedure (MOP) that is specific to your environment to reduce the risk of variance or omitted steps when running the upgrade process.

  • You can use representative hardware in a staging environment to prepare a MOP and validate any content changes.

    • Include a cross-section of firmware versions, additional interface or device hardware, and any additional software in the representative staging environment to ensure that it is broadly representative of the variety that is present in the production environments.
    • Ensure that you validate any Red Hat Enterprise Linux update or upgrade in the representative staging environment.
  • Use Satellite for localized and version-pinned RPM content for your control plane and data plane.
  • In the production environment, use the content that you tested in the staging environment.

1.6. Upgrade framework for long life versions
Link kopieren

You can use the Red Hat OpenStack Platform (RHOSP) upgrade framework to perform an in-place upgrade path through multiple versions of the overcloud. The goal is to provide you with an opportunity to remain on certain OpenStack versions that are considered long life versions and upgrade when the next long life version is available.

The Red Hat OpenStack Platform upgrade process also upgrades the version of Red Hat Enterprise Linux (RHEL) on your nodes.

This guide provides an upgrade framework through the following versions:

Expand
Current VersionTarget Version

Red Hat OpenStack Platform 16.2.4 and later

Red Hat OpenStack Platform 17.1 latest

For detailed support dates and information on the lifecycle support for Red Hat OpenStack Platform, see Red Hat OpenStack Platform Life Cycle.

Upgrade paths for long life releases

Familiarize yourself with the possible update and upgrade paths before you begin an upgrade. If you are using an environment that is earlier than RHOSP 16.2.4, before you upgrade from major version to major version, you must first update your existing environment to the latest minor release.

For example, if your current deployment is Red Hat OpenStack Platform (RHOSP) 16.2.1 on Red Hat Enterprise Linux (RHEL) 8.4, you must perform a minor update to the latest RHOSP 16.2 version before you upgrade to RHOSP 17.1.

Note

You can view your current RHOSP and RHEL versions in the /etc/rhosp-release and /etc/redhat-release files.

Expand
Table 1.1. Updates version path

Current version

Target version

RHOSP 16.2.x on RHEL 8.4

RHOSP 16.2 latest on RHEL 8.4 latest

RHOSP 17.0.x on RHEL 9.0

RHOSP 17.0 latest on RHEL 9.0 latest

RHOSP 17.0.x on RHEL 9.0

RHOSP 17.1 latest on RHEL 9.2 latest

RHOSP 17.1.x on RHEL 9.2

RHOSP 17.1 latest on RHEL 9.2 latest

For more information, see Performing a minor update of Red Hat OpenStack Platform.

Expand
Table 1.2. Upgrades version path

Current version

Target version

RHOSP 16.2 on RHEL 8.4

RHOSP 17.1 latest on RHEL 9.2 latest

Red Hat provides two options for upgrading your environment to the next long life release:

In-place upgrade
Perform an upgrade of the services in your existing environment. This guide primarily focuses on this option.
Parallel migration
Create a new RHOSP 17.1 environment and migrate your workloads from your current environment to the new environment. For more information about RHOSP parallel migration, contact Red Hat Global Professional Services.

1.7. Upgrade duration and impact
Link kopieren

The durations in the following table were recorded in a test environment that consisted of an overcloud with 200 nodes, and 9 Ceph Storage hosts with 17 object storage daemons (OSDs) each. The durations in the table might not apply to all production environments. For example, if your hardware has low specifications or an extended boot period, allow for more time with these durations. Durations also depend on network I/O to container and package content, and disk I/O on the host.

To accurately estimate the upgrade duration for each task, perform these procedures in a test environment with hardware that is similar to your production environment.

Expand
Table 1.3. Duration and impact of In-place upgrade
 DurationNotes

Undercloud upgrade

  • 30 minutes
  • No disruption to the overcloud.

Overcloud adoption and preparation

  • 10 minutes for bare metal adoption
  • 30 minutes for upgrade prepare
  • Duration scales based on the size of the overcloud.
  • No disruption to the overcloud.

Red Hat Ceph Storage upgrade

  • Ceph upgrade ansible run: 90 minutes total, 10 minutes per node
  • Ceph ansible run for cephadm adoption: 30 minutes total, 3 minutes per node
  • Post ceph upgrade and adoption overcloud upgrade prepare: 20 minutes
  • Duration scales based on the number of Red Hat Ceph Storage hosts and OSDs.
  • Storage performance is degraded.

Overcloud OpenStack upgrade

  • 120 minutes
  • Duration scales based on the size of the overcloud.
  • During this process, agents are restarted and API transactions might be lost. Disable client access to the OpenStack API during this stage.
  • Workloads that are running in the overcloud remain active.

  • The upgrade does not affect the following:

    • Red Hat Ceph Storage OSDs (back-end storage for instances)
    • Network connectivity (East-West, North-South)
    • Undercloud

Undercloud system upgrade

  • 40 minutes
  • Includes multiple reboots. Reboot times are hardware dependent.
  • Includes SELinux relabeling. Hosts with large numbers of files take significantly longer.
  • No disruption to the overcloud.

Overcloud non-Compute host system upgrade

  • 30 minutes for upgrade prepare
  • 40 minutes per host system upgrade
  • Includes multiple reboots. Reboot times are hardware dependent.
  • Workloads that are running in the overcloud remain active.
  • Includes SELinux relabeling. Hosts with large numbers of files take significantly longer.
  • Performance is degraded.

Overcloud Compute host upgrade

  • 40 minutes per batch of hosts
  • 30 minutes for upgrade prepare
  • You run upgrade prepare on select batches of Compute nodes. The duration depends on the number of Compute nodes in each batch. There is no outage.
  • Includes multiple reboots. Reboot times are hardware dependent.
  • Includes SELinux relabeling. Hosts with large numbers of files take significantly longer.
  • To prevent workload outages during the reboot, you can migrate the workloads to another host beforehand.

1.8. Known issues that might block an upgrade
Link kopieren

For more information about the known issues that might affect a successful upgrade, see Known issues that might block a RHOSP 17.1 upgrade.

Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben