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.
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 Version | Target 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.
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.
| In-place upgrade | Parallel migration | |
|---|---|---|
| Upgrade duration for undercloud | Estimated duration for each major action includes the following:
| None. You are creating a new undercloud in addition to your existing undercloud. |
| Upgrade duration for overcloud control plane | Estimates for each Controller node:
| 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:
| 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. |
