Upgrading
Understanding upgrading options for Red Hat OpenShift Service on AWS
Abstract
Chapter 1. Upgrading ROSA with HCP clusters
1.1. Upgrade options for ROSA with HCP clusters
In OpenShift, upgrading means provisioning a new component with updated software and using it to replace an existing component that has outdated software.
You can control the impact of upgrades to your workload by controlling which parts of the cluster are upgraded, for example:
- Upgrade only the hosted control plane
- This initiates upgrade of the hosted control plane. It does not impact your worker nodes.
- Upgrade nodes in a machine pool
- This initiates a rolling replacement of nodes in the specified machine pool, and temporarily impacts the worker nodes on that machine pool. You can also upgrade multiple machine pools concurrently.
You cannot upgrade the hosted control plane at the same time as any machine pool upgrade.
To maintain compatibility between nodes in the cluster, nodes in machine pools cannot use a newer version than the hosted control plane. This means that the hosted control plane should always be upgraded to a given version before any machine pools are upgraded to the same version.
You can further control the time required for a machine pool upgrade, and the impact of an upgrade to your workload, by editing the --max-surge
and --max-unavailable
values for each machine pool. These options control the number of nodes that can be upgraded simultaneously on a machine pool, and whether an upgrade provisions excess nodes or makes some existing nodes unavailable or both, for example:
-
To prioritize high workload availability, you can provision excess nodes instead of making existing nodes unavailable by setting a higher value for
--max-surge
and setting--max-unavailable
to0
. -
To prioritize lower infrastructure costs, you can make some existing nodes unavailable and avoid provisioning excess nodes by setting a higher value for
--max-unavailable
and setting--max-surge
to0
. -
To prioritize upgrade speed by upgrading multiple nodes simultaneously, you can provision excess nodes and allow some existing nodes to be made unavailable by configuring moderate values for both
--max-surge
and--max-unavailable
.
For more information about these parameters and their usage, see the ROSA CLI reference for rosa edit machinepool
.
1.2. Life cycle policies and planning
To plan an upgrade, review the Red Hat OpenShift Service on AWS update life cycle.
The life cycle page includes release definitions, support and upgrade requirements, installation policy information and life cycle dates.
Upgrades are manually initiated or automatically scheduled. Red Hat Site Reliability Engineers (SREs) monitor upgrade progress and remedy any issues encountered.
If your control plane is not currently multi-architecture enabled, the upgrade process will first migrate the cluster to a multi-architecture image and then apply the version upgrade. Multi-architecture clusters are capable of running both x86-based and Arm-based workloads. Clusters created after 25 July, 2024 are multi-architecture enabled by default.
1.3. Upgrading the hosted control plane with the ROSA CLI
You can manually upgrade the hosted control plane of a ROSA with HCP cluster by using the ROSA CLI. This method schedules the control plane for an upgrade if a more recent version is available, either immediately, or at a specified future time.
Your control plane only supports machine pools within two minor Y-stream versions. For example, a ROSA with HCP cluster with a control plane using version 4.15.z supports machine pools with version 4.13.z and 4.14.z, but the control plane does not support machine pools using version 4.12.z.
Prerequisites
- You have installed and configured the latest version of the ROSA CLI.
- No machine pool upgrades are in progress or scheduled to take place at the same time as the hosted control plane upgrade.
Procedure
Verify the current version of your cluster by running the following command:
$ rosa describe cluster --cluster=<cluster_name_or_id> 1
- 1
- Replace
<cluster_name_or_id>
with the cluster name or the cluster ID.
List the versions that you can upgrade your control plane to by running the following command:
$ rosa list upgrade --cluster=<cluster_name_or_id>
The command returns a list of available updates, including the recommended version.
Example output
VERSION NOTES 4.14.8 recommended 4.14.7 4.14.6
Upgrade the cluster’s hosted control plane by running the following command:
$ rosa upgrade cluster -c <cluster_name_or_id> --control-plane [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
To schedule an immediate upgrade to the specified version, run the following command:
$ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --version <version_number>
Your hosted control plane is scheduled for an immediate upgrade.
To schedule an upgrade to the specified version at a future date, run the following command:
$ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version=<version_number>
Your hosted control plane is scheduled for an upgrade at the specified time in Coordinated Universal Time (UTC).
Troubleshooting
- Sometimes a scheduled upgrade does not initiate. See Upgrade maintenance canceled for more information.
1.4. Upgrading machine pools with the ROSA CLI
You can manually upgrade one or more machine pools in a ROSA with HCP cluster by using the ROSA CLI. This method schedules the specified machine pool for an upgrade if a more recent version is available, either immediately, or at a specified future time.
Your control plane only supports machine pools within two minor Y-stream versions. For example, a ROSA with HCP cluster with a control plane using version 4.15.z supports machine pools with version 4.13.z and 4.14.z, but the control plane does not support machine pools using version 4.12.z.
Prerequisites
- You have installed and configured the latest version of the ROSA CLI.
- No upgrades for the hosted control plane are in progress on the cluster, or scheduled to occur at the same time as the machine pool upgrade.
Procedure
Verify the current version of your cluster by running the following command:
$ rosa describe cluster --cluster=<cluster_name_or_id> 1
- 1
- Replace
<cluster_name_or_id>
with the cluster name or the cluster ID.
Example output
OpenShift Version: 4.14.0
List the versions that you can upgrade your machine pools to by running the following command:
$ rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>
The command returns a list of available updates, including the recommended version.
Example output
VERSION NOTES 4.14.5 recommended 4.14.4 4.14.3
ImportantDo not upgrade your machine pool to a version higher than your control plane. If you want to move to a higher version, upgrade the control plane to that version first.
Verify the upgrade behavior of the machine pools you intend to upgrade by running the following command:
$ rosa describe machinepool --cluster=<cluster_name_or_id> <machinepool_name>
Example output
Replicas: 5 Node drain grace period: 30 minutes Management upgrade: - Type: Replace - Max surge: 20% - Max unavailable: 20%
In the example, these settings allow the machine pool to provision one excess node (
max-surge
of 20% ofreplicas
) and to have up to one node unavailable (max-unavailable
of 20% ofreplicas
) during an upgrade. This machine pool can therefore upgrade two nodes at a time, by provisioning one new node in excess of the replica count, and by making one node unavailable and replacing it. Node upgrades may be delayed by up to 30 minutes (node-drain-grace-period
of 30 minutes) if necessary to protect workloads that have a pod disruption budget.Upgrade a machine pool by running the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
You can upgrade multiple machine pools concurrently by running this command for each machine pool you want to upgrade.
To schedule the immediate upgrade of a machine pool, run the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --version <version_number>
The machine pool is scheduled for immediate upgrade, which initiates a rolling replacement of all nodes in the specified machine pool.
To schedule an upgrade to start at a future time, run the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version <version_number>
The machine pool is scheduled to begin an upgrade at the specified time and date in Coordinated Universal Time (UTC). This will initiate a rolling replacement of all nodes in the specified machine pool, beginning at the specified time.
1.5. Upgrading the whole cluster with the ROSA CLI
Upgrading the entire cluster involves upgrading both the hosted control plane and nodes in the machine pools. However, these components cannot be upgraded at the same time. They must be upgraded in sequence. This can be done in any order. However, to maintain compatibility between nodes in the cluster, nodes in machine pools cannot use a newer version than the hosted control plane. Therefore, if both the hosted control plane and the nodes in your machine pools require upgrade to the same OpenShift version, you must upgrade the hosted control plane first, followed by the machine pools.
Prerequisites
- You have installed and configured the latest version of the ROSA CLI.
- No other upgrades are in progress or scheduled to take place at the same time as this upgrade.
1.5.1. Upgrading the hosted control plane
When you need to upgrade the whole cluster, upgrade the hosted control plane first.
Prerequisites
- You have installed and configured the latest version of the ROSA CLI.
- No machine pool upgrades are in progress or scheduled to take place at the same time as the hosted control plane upgrade.
Procedure
Verify the current version of your cluster by running the following command:
$ rosa describe cluster --cluster=<cluster_name_or_id> 1
- 1
- Replace
<cluster_name_or_id>
with the cluster name or the cluster ID.
List the versions that you can upgrade your control plane to by running the following command:
$ rosa list upgrade --cluster=<cluster_name_or_id>
The command returns a list of available updates, including the recommended version.
Example output
VERSION NOTES 4.14.8 recommended 4.14.7 4.14.6
Upgrade the cluster’s hosted control plane by running the following command:
$ rosa upgrade cluster -c <cluster_name_or_id> --control-plane [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
To schedule an immediate upgrade to the specified version, run the following command:
$ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --version <version_number>
Your hosted control plane is scheduled for an immediate upgrade.
To schedule an upgrade to the specified version at a future date, run the following command:
$ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version=<version_number>
Your hosted control plane is scheduled for an upgrade at the specified time in Coordinated Universal Time (UTC).
1.5.2. Upgrading machine pools
When your hosted control plane upgrade is complete, you can upgrade one or more machine pools.
Procedure
Verify the current version of your cluster by running the following command:
$ rosa describe cluster --cluster=<cluster_name_or_id> 1
- 1
- Replace
<cluster_name_or_id>
with the cluster name or the cluster ID.
Example output
OpenShift Version: 4.14.8
List the versions that you can upgrade your machine pools to by running the following command:
$ rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>
The command returns a list of available updates, including the recommended version.
Example output
VERSION NOTES 4.14.5 recommended 4.14.4 4.14.3
ImportantDo not upgrade your machine pool to a version higher than your control plane. If you want to move to a higher version, upgrade the control plane to that version first.
Verify the upgrade behavior of the machine pools you intend to upgrade by running the following command:
$ rosa describe machinepool --cluster=<cluster_name_or_id> <machinepool_name>
Example output
Replicas: 5 Node drain grace period: 30 minutes Management upgrade: - Type: Replace - Max surge: 20% - Max unavailable: 20%
In the example, these settings allow the machine pool to provision one excess node (
max-surge
of 20% ofreplicas
) and to have up to one node unavailable (max-unavailable
of 20% ofreplicas
) during an upgrade. This machine pool can therefore upgrade two nodes at a time, by provisioning one new node in excess of the replica count, and by making one node unavailable and replacing it. Node upgrades may be delayed by up to 30 minutes (node-drain-grace-period
of 30 minutes) if necessary to protect workloads that have a pod disruption budget.Upgrade a machine pool by running the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
You can upgrade multiple machine pools concurrently by running this command for each machine pool you want to upgrade.
To schedule the immediate upgrade of a machine pool, run the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --version <version_number>
The machine pool is scheduled for immediate upgrade, which initiates a rolling replacement of all nodes in the specified machine pool.
To schedule an upgrade to start at a future time, run the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version <version_number>
The machine pool is scheduled to begin an upgrade at the specified time and date in Coordinated Universal Time (UTC). This will initiate a rolling replacement of all nodes in the specified machine pool, beginning at the specified time.
1.6. Upgrading with the ROSA CLI
You can manually upgrade a ROSA with HCP cluster by using the ROSA CLI. This method schedules the cluster for an immediate upgrade if a more recent version is available.
Your control plane only supports machine pools within two minor Y-stream versions. For example, a ROSA with HCP cluster with a control plane using version 4.15.z supports machine pools with version 4.13.z and 4.14.z, but the control plane does not support machine pools using version 4.12.z.
Prerequisites
- You have installed and configured the latest version of the ROSA CLI.
Procedure
Verify the current version of your cluster by running the following command:
$ rosa describe cluster --cluster=<cluster_name_or_id> 1
- 1
- Replace
<cluster_name_or_id>
with the cluster name or the cluster ID.
List the versions that you can upgrade your control plane and machine pools to by running the following commands:
For the control plane versions, run the following command:
$ rosa list upgrade --cluster=<cluster_name|cluster_id>
The command returns a list of available updates, including the recommended version.
Example output
VERSION NOTES 4.14.8 recommended 4.14.7 4.14.6
For the machine pool versions, run the following command:
$ rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>
The command returns a list of available updates, including the recommended version.
Example output
VERSION NOTES 4.14.5 recommended 4.14.4 4.14.3
NoteThe latest available update for machine pools is limited to the current current version of the control plane. Ensure your control plane is up to date first.
Upgrade your cluster with one of the following options:
Upgrade the cluster’s hosted control plane by running the following command:
$ rosa upgrade cluster -c <cluster_name> --control-plane [--schedule-date=XX --schedule-time=XX] [--version <version_number>]
Your hosted control plane is now scheduled for an upgrade.
Upgrade a specific machine pool on your cluster by running the following command:
$ rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=XX --schedule-time=XX] [--version <version_number>]
Your machine pool is now scheduled for an upgrade.
Chapter 2. Upgrading ROSA (classic architecture) clusters
Use one of the following methods to upgrade ROSA (classic architecture) clusters:
-
Manually through the ROSA CLI (
rosa
) - Start a one-time immediate upgrade or schedule a one-time upgrade for a future date or time. - Manually through the OpenShift Cluster Manager UI - Start a one-time immediate upgrade or schedule a one-time upgrade for a future date or time; or schedule an upgrade window for automatic recurring upgrades whenever a new z-version is available.
2.1. Life cycle policies and planning
To plan an upgrade, review the Red Hat OpenShift Service on AWS update life cycle. The life cycle page includes release definitions, support and upgrade requirements, installation policy information and life cycle dates.
You can use update channels to decide which Red Hat OpenShift Container Platform minor version to update your clusters to. Red Hat OpenShift Service on AWS supports updates only through the stable
channel. To learn more about OpenShift update channels and releases, see Understanding update channels and releases.
2.2. Upgrading a ROSA Classic cluster
You must upgrade ROSA (classic architecture) clusters using either the ROSA CLI (rosa
) or the OpenShift Cluster Manager console.
The actual start time of the cluster upgrade will be within one hour of the upgrade schedule time. Additionally, the duration of the upgrade might vary based on your workload configuration.
When a ROSA (classic architecture) cluster that uses AWS Security Token Services (STS) is upgraded, the ROSA CLI verifies the account and Operator role policies for the chosen cluster are compatible with the target version of the upgrade. If the policies are compatible, the CLI automatically upgrades the cluster. If the policies are not compatible with the chosen upgrade version, the CLI automatically upgrades IAM policies before upgrading the cluster. When scheduling the upgrade, you give administrative acknowledgment to confirm you have reviewed the changes involved with the upgrade, if required.
2.2.1. How ROSA (classic architecture) cluster upgrades work
Upgrades are manually initiated (one-time) or automatically scheduled (recurring). Red Hat Site Reliability Engineers (SREs) monitor upgrade progress and either proactively notify you to take corrective actions or remedy issues encountered.
The Cluster Version Operator (CVO) is the primary component that orchestrates and facilitates the OpenShift Container Platform update process.
The Managed Upgrade Operator (MUO) handles the scheduling, monitoring, and notifications of ROSA (classic architecture) cluster upgrades. The MUO orchestrates the automated in-place cluster upgrades by ensuring the operating conditions are met before and after the upgrade of a managed cluster.
2.2.1.1. Cluster upgrade scheduled time
You can schedule cluster upgrades by setting the scheduled time. This is when the preparation for the cluster upgrade begins with pre-upgrade health checks and additional compute capacity creation. The actual cluster upgrade starts within one hour from the scheduled time. You receive an email notification when the cluster upgrade starts.
The Pre-Health Check (PHC) provides extra protection to ensure the scheduled update proceeds as expected and runs in the following two scenarios:
- If an upgrade is scheduled for more than 2 hours from the current time, the PHC runs and the user is notified if there are any failures. This PHC is in the New phase of the upgrade.
- When the upgrade is immediate or within 2 hours, the PHC runs just before the upgrade begins. This PHC is in the Upgrading phase of the upgrade. This means that PHC is always run at least one time during the upgrading phase but can also be run additionally in advance if the upgrade is scheduled for more than 2 hours from the current time.
You can observe the status of the cluster upgrade by running the rosa describe upgrade --cluster=<cluster name|cluster_id>
command in the ROSA CLI (rosa
).
2.2.1.2. ROSA (classic architecture) upgrade overview
The following are the high-level steps that occur during the ROSA (classic architecture) cluster update:
-
Scheduling the upgrade in advance triggers the
PreHealthCheck
and notifies users of any failures that they can then address before the upgrade begins. Before the cluster upgrade begins, a cluster health check is performed by the MUO. If the MUO identifies an issue that requires corrective action, you will be notified. Some examples of the cluster health checks that MUO performs include:
- Identifying any Pod Disruption Budgets (PDBs) that can potentially block or delay the update of the nodes.
- Ensuring cluster Operators are available and healthy.
- Ensuring cluster critical alerts are not firing.
A temporary compute node is created in the cluster to allow for the scheduling of drained pods during the update.
NoteThe temporary compute node creation does not always happen. For example, if there is no
worker
machine pool, the temporary compute node will not be created. This might happen when a cluster admin deletes the existingworker
machine pool and creates anotherworker
machine pool with a different name or instance type.The cluster version is set to the target version.
NoteIn certain situations, an upgrade path can become unavailable since the time the cluster update was requested but before it was completed. In such cases, the upgrade is automatically canceled and a notification is sent. You must pick another target version to request the upgrade.
- During the upgrade, the control plane components are updated to the new version.
- Next, individual cluster Operators perform update tasks on their domain of the cluster.
Finally, the MCO updates the system configuration and operating system of every node. During this step, each node is rebooted after successfully draining the workloads running on the node.
- During the update of each node, workloads are drained, honoring the PDBs. Workloads with PDBs that do not allow disruptions essentially block the draining of the node, increasing the elapsed time for the cluster update.
- During the update of every node in the cluster, the cluster update waits until the time specified by the node drain grace period to allow for safely draining the workloads. Upon reaching the node drain grace period, the node is forcibly drained to allow for cluster upgrade to progress. You can only configure the node drain grace period before initiating the upgrade and you cannot change it after the cluster upgrade begins.
- When cluster nodes are updated, the MCO selects one node at a time per machine config pool according to their age, starting with the oldest.
2.2.2. Upgrading with the ROSA CLI
You can use the ROSA CLI (rosa
) to upgrade a Red Hat OpenShift Service on AWS (ROSA) cluster either immediately within one hour or at a future time.
Prerequisites
- You have installed and configured the latest ROSA CLI on your installation host.
-
Your Red Hat OpenShift Service on AWS cluster is in a
Ready
state.
Procedure
To verify the current version of your cluster, enter the following command:
$ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
- 1
- Replace
<cluster_name|cluster_id>
with the cluster name or the ID of the cluster.
To verify that an upgrade is available, enter the following command:
$ rosa list upgrade --cluster=<cluster_name|cluster_id>
The command returns a list of versions to which the cluster can be upgraded, including a recommended version. The recommendation is based on the conditional update risks. Each known risk might apply to all clusters or only clusters matching certain conditions. Refer to the OpenShift release notes to evaluate, validate and determine the appropriate version to upgrade to.
To upgrade the cluster to a specified version immediately within the next hour, enter the following command:
$ rosa upgrade cluster --cluster=<cluster_name|cluster_id> --version <version-id>
NoteIf you are upgrading an AWS Security Token Service (STS) cluster, this command starts an interactive IAM Roles/policies upgrade mode process that verifies the account and operator role policies for the chosen cluster are compatible with the target version of the upgrade. If the policies are not compatible with the chosen upgrade version, the CLI automatically upgrades them in auto mode.
The cluster is scheduled for an immediate upgrade as denoted by the Scheduled Time. The upgrade will begin within one hour from the scheduled time.
Alternatively, to upgrade the cluster at a future time in UTC, enter the following command:
$ rosa upgrade cluster --cluster=<cluster_name|cluster_id> \ --version <version-id> \ --schedule-date yyyy-mm-dd \ --schedule-time HH:mm
To customize the grace period for every node to be drained during the cluster upgrade, enter the following command:
$ rosa upgrade cluster --cluster=<cluster_name|cluster_id> \ --version <version-id> \ --node-drain-grace-period 15 minutes
You can view the status of the upgrade by entering the following command, which shows both the status (scheduled or started) and the scheduled time.
$ rosa list upgrade --cluster=<cluster_name|cluster_id>
Example output
VERSION NOTES 4.15.14 recommended - scheduled for 2024-06-02 15:00 UTC 4.15.13
You will receive email notifications confirming the scheduling, beginning, and completion of the cluster upgrade.
Troubleshooting
- Sometimes a scheduled upgrade does not trigger. See Upgrade maintenance cancelled for more information.
2.2.3. Deleting a ROSA cluster upgrade with the ROSA CLI
You can use either the ROSA CLI (rosa
) or OpenShift Cluster Manager console to delete a scheduled upgrade. This procedure uses the ROSA CLI.
Procedure
Verify the cluster update has not started using the following command:
$ rosa list upgrades --cluster=<cluster_name|cluster_id>
Example output
VERSION NOTES 4.15.14 recommended - scheduled for 2024-06-02 15:00 UTC 4.15.13
Delete a scheduled update by running the following command:
$ rosa delete upgrade --cluster=<cluster_name|cluster_id>
Confirm the deletion by entering
Yes
at the confirmation prompt.Example output
I: Successfully canceled scheduled upgrade on cluster 'my-cluster'
You will receive an email notification confirming that the scheduled upgrade has been canceled.
2.2.4. Upgrading with the OpenShift Cluster Manager console
You can schedule upgrades for a ROSA (classic architecture) cluster manually either one time or on a recurring schedule by using OpenShift Cluster Manager console.
Procedure
- Log in to OpenShift Cluster Manager.
- Select a cluster to upgrade.
- Click the Settings tab.
In the Update strategy pane, select which type of update you want:
- For individual updates, you can request the upgrade either immediately (to start within an hour) or at a future time.
For recurring updates, choose a recurring date and time to start the upgrade automatically to the latest x.y.Z (z-stream) version available.
ImportantRecurring updates are applicable only for z-stream updates. Minor version or y-stream updates need to be done manually. You will be notified when a new y-stream update is available.
Optional: In the Node draining pane, select a grace period interval from the list. The grace period enables the nodes to gracefully drain before forcing the pod eviction. The default is 1 hour.
ImportantYou cannot change the node drain grace period after you start the upgrade process.
- In the Update strategy pane, click Save to apply your update strategy.
In the Update status pane, review the Update available information and click Update.
NoteThe Update button is enabled only when an upgrade is available.
- The Update cluster dialog opens. Recommended cluster upgrades appear in the Select version pane. Select the version you want to upgrade your cluster to, and click Next.
Optional: For ROSA clusters that use AWS Security Token Service (STS), the account-level and cluster-specific Operator roles might need to be updated, depending on the selected target version.
-
In the ROSA CLI, run the
rosa list account-roles
command to list and verify that the account roles are compatible with the target minor version chosen for the upgrade. If the roles are not compatible, run therosa upgrade account-roles
command to upgrade the account roles to the latest OpenShift version. -
In the ROSA CLI, run the
rosa list operator-roles
command to list and verify that Operator roles associated with the cluster are compatible with the target minor version chosen for the upgrade. If not, run therosa upgrade operators-roles
command to upgrade the cluster’s Operator roles to the latest OpenShift version. - If you select an update version that requires approval, provide an administrator’s acknowledgment by typing Acknowledge into the field provided, and click Next.
-
In the ROSA CLI, run the
In the Schedule update dialog, schedule your cluster upgrade.
- To upgrade within an hour, select Update now and click Next.
- To upgrade at a later time, select Schedule a different time and set a time and date for your upgrade. Click Next to proceed to the confirmation dialog.
- After reviewing the version and schedule summary, select Confirm update.
- Click Close to exit out of the Update cluster dialog.
The cluster is scheduled for an upgrade to the target version. This action can take up to an hour, depending on the selected upgrade schedule and your workload configuration, such as pod disruption budgets.
The status is displayed in the Update status pane.
Troubleshooting
- Sometimes a scheduled upgrade does not trigger. See Upgrade maintenance cancelled for more information.
2.2.5. Deleting a ROSA cluster upgrade with the OpenShift Cluster Manager console
You can use the OpenShift Cluster Manager console to delete a scheduled upgrade.
Procedure
- Log in to OpenShift Cluster Manager.
- Select the cluster with the scheduled upgrade.
- Click the Settings tab.
- In the Update status pane, click Cancel this update.
- Review the update details in the Cancel update dialog and click Cancel this update.
You will receive an email notification confirming that the scheduled upgrade has been canceled.
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.