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

The Red Hat OpenStack Platform framework for upgrades is a workflow to upgrade your Red Hat OpenStack Platform 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.

1.1. Upgrade framework for long life versions

You can use the Red Hat OpenStack Platform 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.

Important

You can upgrade Red Hat OpenStack Platform 13 to Red Hat OpenStack Platform 16.1. However, to avail of full product support, only the Red Hat OpenStack Platform 13 to Red Hat OpenStack Platform 16.2 upgrade path is supported. If you want to upgrade from 13 to 16.1, you must obtain a Support Exception.

For more information about upgrading to Red Hat OpenStack Platform 16.2, see Framework for upgrades 13 to 16.2.

This guide provides an upgrade framework through the following versions:

Current VersionTarget Version

Red Hat OpenStack Platform 13

Red Hat OpenStack Platform 16.1

1.2. Lifecycle support for long life versions

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

1.3. Upgrade paths for long life release

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 Red Hat OpenStack Platform 16.1 environment and migrate your workloads from your current environment to the new environment. For more information about Red Hat OpenStack Platform parallel migration, contact Red Hat Global Professional Services.
Important

The durations in this table are minimal estimates based on internal testing and might not apply to all productions environments. For example, if your hardware has low specifications or an extended boot period, allow for more time with these durations. To accurately gauge the upgrade duration for each task, perform these procedures in a test environment with hardware similar to your production environment.

Table 1.1. Impact and duration of upgrade paths

 In-place upgradeParallel migration

Upgrade duration for undercloud

Estimated duration for each major action includes the following:

  • 30 minutes for Leapp upgrade command
  • 30 minutes for Leapp reboot
  • 40 minutes for director upgrade

None. You are creating a new undercloud in addition to your existing undercloud.

Upgrade duration for overcloud control plane

Estimates for each Controller node:

  • 60 minutes for Leapp upgrade and reboot
  • 60 minutes for service upgrade

None. You are creating a new control plane in addition to your existing control plane.

Outage duration for control plane

The duration of the service upgrade of the bootstrap Controller node, which is approximately 60 minutes.

None. Both overclouds are operational during the workload migration.

Consequences of control plane outage

You cannot perform OpenStack operations during the outage.

No outage.

Upgrade duration for overcloud data plane

Estimates for each Compute node and Ceph Storage node:

  • 60 minutes for Leapp upgrade and reboot
  • 30 minutes for service upgrade

None. You are creating a new data plane in addition to your existing data plane.

Outage duration for data plane

The outage is minimal due to workload migration from node to node.

The outage is minimal due to workload migration from overcloud to overcloud.

Additional hardware requirements

No additional hardware is required.

Additional hardware is required to create a new undercloud and overcloud.