Merge pull request #40705 from kelbrown20/OSDOCS-3154-update-installer-for-arm

OSDOCS-3154: Adding clarification for choosing the correct OS and architecture
2026-02-05 12:46:18 +01:00 · 2022-02-08 10:26:16 -05:00
parent 4fa56cc723
commit 498e496636
17 changed files with 391 additions and 39 deletions
--- a/_topic_maps/_topic_map_osd.yml
+++ b/_topic_maps/_topic_map_osd.yml
@@ -93,6 +93,9 @@ Name: Upgrading
 Dir: upgrading
 Distros: openshift-dedicated
 Topics:
+- Name: Preparing to upgrade OpenShift Dedicated to 4.9
+  File: osd-upgrading-cluster-prepare
+  Distros: openshift-dedicated
 - Name: Upgrading OpenShift Dedicated
  File: osd-upgrades
  Distros: openshift-dedicated
--- a/_topic_maps/_topic_map_rosa.yml
+++ b/_topic_maps/_topic_map_rosa.yml
@@ -128,6 +128,9 @@ Name: Upgrading
 Dir: upgrading
 Distros: openshift-rosa
 Topics:
+- Name: Preparing to upgrade ROSA to 4.9
+  File: rosa-upgrading-cluster-prepare
+  Distros: openshift-rosa
 - Name: Upgrading ROSA
  File: rosa-upgrading
  Distros: openshift-rosa
--- a/modules/osd-update-preparing-evaluate-alerts.adoc
+++ b/modules/osd-update-preparing-evaluate-alerts.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-updating-cluster-prepare.adoc
+// * upgrading/osd-updating-cluster-prepare.adoc
+
+[id="update-preparing-evaluate-alerts_{context}"]
+= Reviewing alerts to identify uses of removed APIs
+
+The `APIRemovedInNextReleaseInUse` alert tells you that there are removed APIs in use on your cluster. If this alert is firing in your cluster, review the alert; take action to clear the alert by migrating manifests and API clients to use the new API version. You can use the `APIRequestCount` API to get more information about which APIs are in use and which workloads are using removed APIs.
--- a/modules/osd-update-preparing-evaluate-apirequestcount-workloads.adoc
+++ b/modules/osd-update-preparing-evaluate-apirequestcount-workloads.adoc
@@ -0,0 +1,45 @@
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-updating-cluster-prepare.adoc
+// * upgrading/osd-updating-cluster-prepare.adoc
+
+:_content-type: PROCEDURE
+[id="update-preparing-evaluate-apirequestcount-workloads_{context}"]
+= Using APIRequestCount to identify which workloads are using the removed APIs
+
+You can examine the `APIRequestCount` resource for a given API version to help identify which workloads are using the API.
+
+.Prerequisites
+
+* You must have access to the cluster as a user with the `cluster-admin` role.
+
+.Procedure
+
+* Run the following command and examine the `username` and `userAgent` fields to help identify the workloads that are using the API:
+
+[source,terminal]
+----
+$ oc get apirequestcounts <resource>.<version>.<group> -o yaml
+----
+
+For example:
+
+[source,terminal]
+----
+$ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o yaml
+----
+
+You can also use `-o jsonpath` to extract the `username` values from an `APIRequestCount` resource:
+
+[source,terminal]
+----
+$ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o jsonpath='{range ..username}{$}{"\n"}{end}' | sort | uniq
+----
+
+.Example output
+[source,terminal]
+----
+user1
+user2
+app:serviceaccount:delta
+----
--- a/modules/osd-update-preparing-evaluate-apirequestcount.adoc
+++ b/modules/osd-update-preparing-evaluate-apirequestcount.adoc
@@ -0,0 +1,58 @@
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-updating-cluster-prepare.adoc
+// * upgrading/osd-updating-cluster-prepare.adoc
+
+:_content-type: PROCEDURE
+[id="update-preparing-evaluate-apirequestcount_{context}"]
+= Using APIRequestCount to identify uses of removed APIs
+
+You can use the `APIRequestCount` API to track API requests and review if any of them are using one of the removed APIs.
+
+.Prerequisites
+
+* You must have access to the cluster as a user with the `cluster-admin` role.
+
+.Procedure
+
+* Run the following command and examine the `REMOVEDINRELEASE` column of the output to identify the removed APIs that are currently in use:
+
+[source,terminal]
+----
+$ oc get apirequestcounts
+----
+
+.Example output
+[source,terminal]
+----
+NAME                                        REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
+cloudcredentials.v1.operator.openshift.io                      32                      111
+ingresses.v1.networking.k8s.io                                 28                      110
+ingresses.v1beta1.extensions                1.22               16                      66
+ingresses.v1beta1.networking.k8s.io         1.22               0                       1
+installplans.v1alpha1.operators.coreos.com                     93                      167
+...
+----
+
+[NOTE]
+====
+You can safely ignore the following entries that appear in the results:
+
+* `system:serviceaccount:kube-system:generic-garbage-collector` appears in the results because it walks through all registered APIs searching for resources to remove.
+* `system:kube-controller-manager` appears in the results because it walks through all resources to count them while enforcing quotas.
+====
+
+You can also use `-o jsonpath` to filter the results:
+
+[source,terminal]
+----
+$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'
+----
+
+.Example output
+[source,terminal]
+----
+1.22    certificatesigningrequests.v1beta1.certificates.k8s.io
+1.22    ingresses.v1beta1.extensions
+1.22    ingresses.v1beta1.networking.k8s.io
+----
--- a/modules/osd-update-preparing-list.adoc
+++ b/modules/osd-update-preparing-list.adoc
@@ -0,0 +1,105 @@
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-updating-cluster-prepare.adoc
+// * upgrading/osd-updating-cluster-prepare.adoc
+
+[id="update-preparing-list_{context}"]
+= Removed Kubernetes APIs
+
+// TODO: Keep michael's section in the release notes (which this duplicates), or link to this from his RN section?
+{product-title} 4.9 uses Kubernetes 1.22, which removed the following deprecated `v1beta1` APIs. You must migrate manifests and API clients to use the `v1` API version. For more information about migrating removed APIs, see the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22[Kubernetes documentation].
+
+.`v1beta1` APIs removed from Kubernetes 1.22
+[cols="2,2,1",options="header",]
+|===
+|Resource |API |Notable changes
+
+|APIService
+|apiregistration.k8s.io/v1beta1
+|No
+
+|CertificateSigningRequest
+|certificates.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#certificatesigningrequest-v122[Yes]
+
+|ClusterRole
+|rbac.authorization.k8s.io/v1beta1
+|No
+
+|ClusterRoleBinding
+|rbac.authorization.k8s.io/v1beta1
+|No
+
+|CSIDriver
+|storage.k8s.io/v1beta1
+|No
+
+|CSINode
+|storage.k8s.io/v1beta1
+|No
+
+|CustomResourceDefinition
+|apiextensions.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#customresourcedefinition-v122[Yes]
+
+|Ingress
+|extensions/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122[Yes]
+
+|Ingress
+|networking.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122[Yes]
+
+|IngressClass
+|networking.k8s.io/v1beta1
+|No
+
+|Lease
+|coordination.k8s.io/v1beta1
+|No
+
+|LocalSubjectAccessReview
+|authorization.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#subjectaccessreview-resources-v122[Yes]
+
+|MutatingWebhookConfiguration
+|admissionregistration.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#webhook-resources-v122[Yes]
+
+|PriorityClass
+|scheduling.k8s.io/v1beta1
+|No
+
+|Role
+|rbac.authorization.k8s.io/v1beta1
+|No
+
+|RoleBinding
+|rbac.authorization.k8s.io/v1beta1
+|No
+
+|SelfSubjectAccessReview
+|authorization.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#subjectaccessreview-resources-v122[Yes]
+
+|StorageClass
+|storage.k8s.io/v1beta1
+|No
+
+|SubjectAccessReview
+|authorization.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#subjectaccessreview-resources-v122[Yes]
+
+|TokenReview
+|authentication.k8s.io/v1beta1
+|No
+
+|ValidatingWebhookConfiguration
+|admissionregistration.k8s.io/v1beta1
+|link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#webhook-resources-v122[Yes]
+
+|VolumeAttachment
+|storage.k8s.io/v1beta1
+|No
+
+|===
--- a/modules/osd-update-preparing-migrate.adoc
+++ b/modules/osd-update-preparing-migrate.adoc
@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-updating-cluster-prepare.adoc
+// * upgrading/osd-updating-cluster-prepare.adoc
+
+[id="update-preparing-migrate_{context}"]
+= Migrating instances of removed APIs
+
+For information on how to migrate removed Kubernetes APIs, see the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22[Deprecated API Migration Guide] in the Kubernetes documentation.
--- a/modules/rosa-upgrading-cli-tutorial.adoc
+++ b/modules/rosa-upgrading-cli-tutorial.adoc
@@ -9,7 +9,7 @@ endif::[]

 :_content-type: PROCEDURE
 [id="rosa-upgrading-cli_{context}"]
-= Upgrading manually with the rosa CLI
+= Upgrading with the rosa CLI

 You can upgrade a {product-title} cluster
 ifdef::sts[]
@@ -23,7 +23,7 @@ This method schedules the cluster for an immediate upgrade, if a more recent ver

 * You have installed and configured the latest ROSA CLI on your installation host.
 ifdef::sts[]
-* If you are upgrading your cluster from 4.7 to 4.8, you have upgraded the AWS Identity and Access Management (IAM) account-wide roles and policies to version 4.8. You have also updated the `cloudcredential.openshift.io/upgradeable-to` annotation in the `CloudCredential` custom resource. For more information, see _Preparing an upgrade from 4.7 to 4.8_.
+* If you are upgrading your cluster from 4.7 to 4.8, you have upgraded the AWS Identity and Access Management (IAM) account-wide roles and policies to version 4.8. You have also updated the `cloudcredential.openshift.io/upgradeable-to` annotation in the `CloudCredential` custom resource.
 endif::sts[]

 .Procedure
--- a/modules/rosa-upgrading-manual-ocm.adoc
+++ b/modules/rosa-upgrading-manual-ocm.adoc
@@ -9,11 +9,11 @@ endif::[]

 :_content-type: PROCEDURE
 [id="rosa-upgrade-ocm_{context}"]
-= Upgrading manually using the console
+= Upgrading using the console

 You can upgrade a {product-title} cluster
 ifdef::sts[]
-that uses the AWS Security Token Service (STS) 
+that uses the AWS Security Token Service (STS)
 endif::sts[]
 manually by using the OpenShift Cluster Manager (OCM) console.

@@ -28,7 +28,7 @@ endif::sts[]
 . Log in to the {console-redhat-com}.
 . Select a cluster to upgrade.
 . Click the *Settings* tab.
-. In the *Update strategy* pane, click *Manual*.
+. In the *Update strategy* pane, click *Manual* or *Individual Updates*.
 . 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*.
 . 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*.
--- a/modules/rosa-upgrading-preparing-4-7-to-4-8.adoc
+++ b/modules/rosa-upgrading-preparing-4-7-to-4-8.adoc
@@ -1,10 +1,10 @@
 // Module included in the following assemblies:
 //
-// * rosa_upgrading/rosa-upgrading-sts.adoc
+// * upgrading/rosa-upgrading-cluster-prepare.adoc

 :_content-type: PROCEDURE
-[id="rosa-upgrading-4-7-to-4-8-preparing_{context}"]
-= Preparing an upgrade from 4.7 to 4.8
+[id="rosa-upgrading-requirements-48_{context}"]
+= Requirements for upgrading to OpenShift 4.8

 You must meet the following requirements before upgrading a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS) from version 4.7 to 4.8:

@@ -18,27 +18,3 @@ You must meet the following requirements before upgrading a {product-title} (ROS
 * You have installed version 4.8 or later of the OpenShift CLI (`oc`) on your installation host.
 * You have the permissions required to update the AWS account-wide roles and policies.
 * You have access to the cluster as a user with the `cluster-admin` role.
-
-.Procedure
-
-. Update the account-wide roles and policies, including the Operator policies, to version 4.8:
-+
-[source,terminal]
----
-$ rosa create account-roles --mode auto
----
-+
-[IMPORTANT]
-====
-If you created the roles and policies with a custom prefix, you must include the `--prefix` option and specify the same prefix name. Specifying the prefix name ensures that the existing roles and policies used by the cluster are updated. If you did not define a custom prefix, do not use the +
-`--prefix` option.
-====
-
-. As a cluster administrator, update the value of the `cloudcredential.openshift.io/upgradeable-to` annotation in the `CloudCredential` custom resource to `v4.8`:
-+
-[source,terminal]
----
-$ oc annotate cloudcredential cluster cloudcredential.openshift.io/upgradeable-to="v4.8"
----
-
-You can now proceed to upgrade the cluster.
--- a/modules/rosa-upgrading-preparing-4-8-to-4-9.adoc
+++ b/modules/rosa-upgrading-preparing-4-8-to-4-9.adoc
@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-upgrading-cluster-prepare.adoc
+
+:_content-type: PROCEDURE
+[id="rosa-upgrading-requirements-49_{context}"]
+= Requirements for upgrading to OpenShift 4.9
+
+You must meet the following requirements before upgrading a {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS) from version 4.8 to 4.9.
+
+.Prerequisites
+
+* You have installed the latest AWS CLI on your installation host.
+* You have installed link:https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/rosa[version 1.1.9 or later of the ROSA CLI] on your installation host.
+* You have installed version 4.9 or later of the OpenShift CLI (`oc`) on your workstation(s) as needed.
+* You have the permissions required to update the AWS account-wide roles and policies.
+* You have access to the cluster as a user with the `cluster-admin` role.
+* You updated the AWS Identity and Access Management (IAM) account-wide roles and policies, including the Operator policies to version 4.9.
--- a/modules/upgrade-49-acknowledgement.adoc
+++ b/modules/upgrade-49-acknowledgement.adoc
@@ -0,0 +1,15 @@
+
+// Module included in the following assemblies:
+//
+// * upgrading/rosa-cluster-upgrading-prepare.adoc
+// * upgrading/osd-cluster-upgrading-prepare.adoc
+
+:_content-type: CONCEPT
+[id="upgrade-49-acknowledgement_{context}"]
+= Administrator acknowledgment when upgrading to OpenShift 4.9
+
+{product-title} 4.9 uses Kubernetes 1.22, which removed a xref:../release_notes/ocp-4-9-release-notes.adoc#ocp-4-9-removed-kube-1-22-apis[significant number of deprecated `v1beta1` APIs].
+
+{product-title} 4.8.14 introduced a requirement that an administrator must provide a manual acknowledgment before the cluster can be upgraded from {product-title} 4.8 to 4.9. This is to help prevent issues after upgrading to {product-title} 4.9, where APIs that have been removed are still in use by workloads, tools, or other components running on or interacting with the cluster. Administrators must evaluate their cluster for any APIs in use that will be removed and migrate the affected components to use the appropriate new API version. After this is done, the administrator can provide the administrator acknowledgment.
+
+All {product-title} 4.8 clusters require this administrator acknowledgment before they can be upgraded to {product-title} 4.9.
--- a/updating/updating-cluster-prepare.adoc
+++ b/updating/updating-cluster-prepare.adoc
@@ -0,0 +1,36 @@
+:_content-type: ASSEMBLY
+[id="updating-cluster-prepare"]
+= Preparing to update to {product-title} 4.9
+include::modules/common-attributes.adoc[]
+:context: updating-cluster-prepare
+
+toc::[]
+
+{product-title} 4.9 uses Kubernetes 1.22, which removed a significant number of deprecated `v1beta1` APIs.
+
+{product-title} 4.8.14 introduced a requirement that an administrator must provide a manual acknowledgment before the cluster can be upgraded from {product-title} 4.8 to 4.9. This is to help prevent issues after upgrading to {product-title} 4.9, where APIs that have been removed are still in use by workloads, tools, or other components running on or interacting with the cluster. Administrators must evaluate their cluster for any APIs in use that will be removed and migrate the affected components to use the appropriate new API version. After this evaluation and migration is complete, the administrator can provide the acknowledgment.
+
+Before you can upgrade your {product-title} 4.8 cluster to 4.9, you must provide the administrator acknowledgment.
+
+// Removed Kubernetes APIs
+include::modules/update-preparing-list.adoc[leveloffset=+1]
+
+[id="evaluating-cluster-removed-apis"]
+== Evaluating your cluster for removed APIs
+
+There are several methods to help administrators identify where APIs that will be removed are in use. However, {product-title} cannot identify all instances, especially workloads that are idle or external tools that are used. It is the responsibility of the administrator to properly evaluate all workloads and other integrations for instances of removed APIs.
+
+// Reviewing alerts to identify uses of removed APIs
+include::modules/update-preparing-evaluate-alerts.adoc[leveloffset=+2]
+
+// Using APIRequestCount to identify uses of removed APIs
+include::modules/update-preparing-evaluate-apirequestcount.adoc[leveloffset=+2]
+
+// Using APIRequestCount to identify which workloads are using the removed APIs
+include::modules/update-preparing-evaluate-apirequestcount-workloads.adoc[leveloffset=+2]
+
+// Migrating instances of removed APIs
+include::modules/update-preparing-migrate.adoc[leveloffset=+1]
+
+// Providing the administrator acknowledgment
+include::modules/update-preparing-ack.adoc[leveloffset=+1]
--- a/upgrading/osd-upgrading-cluster-prepare.adoc
+++ b/upgrading/osd-upgrading-cluster-prepare.adoc
@@ -0,0 +1,37 @@
+[id="osd-updating-cluster-prepare"]
+= Preparing to upgrade {product-title} to 4.9
+include::modules/common-attributes.adoc[]
+ifdef::openshift-dedicated,openshift-rosa[]
+include::modules/attributes-openshift-dedicated.adoc[]
+endif::[]
+:context: osd-updating-cluster-prepare
+
+toc::[]
+
+Upgrading your {product-title} clusters to OpenShift 4.9 requires you to evaluate and migrate your APIs as the latest version of Kubernetes has removed a significant number of APIs.
+
+Before you can upgrade your {product-title} clusters, you must update the required tools to the appropriate version.
+
+include::modules/upgrade-49-acknowledgement.adoc[leveloffset=+2]
+
+// Removed Kubernetes APIs
+
+// Removed Kubernetes APIs
+include::modules/osd-update-preparing-list.adoc[leveloffset=+2]
+
+[id="osd-evaluating-cluster-removed-apis"]
+== Evaluating your cluster for removed APIs
+
+There are several methods to help administrators identify where APIs that will be removed are in use. However, {product-title} cannot identify all instances, especially workloads that are idle or external tools that are used. It is the responsibility of the administrator to properly evaluate all workloads and other integrations for instances of removed APIs.
+
+// Reviewing alerts to identify uses of removed APIs
+include::modules/osd-update-preparing-evaluate-alerts.adoc[leveloffset=+2]
+
+// Using APIRequestCount to identify uses of removed APIs
+include::modules/osd-update-preparing-evaluate-apirequestcount.adoc[leveloffset=+2]
+
+// Using APIRequestCount to identify which workloads are using the removed APIs
+include::modules/osd-update-preparing-evaluate-apirequestcount-workloads.adoc[leveloffset=+2]
+
+// Migrating instances of removed APIs
+include::modules/osd-update-preparing-migrate.adoc[leveloffset=+1]
--- a/upgrading/rosa-upgrading-cluster-prepare.adoc
+++ b/upgrading/rosa-upgrading-cluster-prepare.adoc
@@ -0,0 +1,37 @@
+[id="rosa-updating-cluster-prepare"]
+= Preparing to upgrade ROSA to 4.9
+include::modules/common-attributes.adoc[]
+ifdef::openshift-dedicated,openshift-rosa[]
+include::modules/attributes-openshift-dedicated.adoc[]
+endif::[]
+:context: rosa-updating-cluster-prepare
+
+toc::[]
+
+Upgrading your {product-title} clusters to OpenShift 4.9 requires you to evaluate and migrate your APIs as the latest version of Kubernetes has removed a significant number of APIs.
+
+Before you can upgrade your {product-title} clusters, you must update the required tools to the appropriate version.
+
+include::modules/rosa-upgrading-preparing-4-8-to-4-9.adoc[leveloffset=+1]
+
+include::modules/upgrade-49-acknowledgement.adoc[leveloffset=+2]
+
+// Removed Kubernetes APIs
+include::modules/osd-update-preparing-list.adoc[leveloffset=+2]
+
+[id="rosa-evaluating-cluster-removed-apis"]
+== Evaluating your cluster for removed APIs
+
+There are several methods to help administrators identify where APIs that will be removed are in use. However, {product-title} cannot identify all instances, especially workloads that are idle or external tools that are used. It is the responsibility of the administrator to properly evaluate all workloads and other integrations for instances of removed APIs.
+
+// Reviewing alerts to identify uses of removed APIs
+include::modules/osd-update-preparing-evaluate-alerts.adoc[leveloffset=+2]
+
+// Using APIRequestCount to identify uses of removed APIs
+include::modules/osd-update-preparing-evaluate-apirequestcount.adoc[leveloffset=+2]
+
+// Using APIRequestCount to identify which workloads are using the removed APIs
+include::modules/osd-update-preparing-evaluate-apirequestcount-workloads.adoc[leveloffset=+2]
+
+// Migrating instances of removed APIs
+include::modules/osd-update-preparing-migrate.adoc[leveloffset=+1]
--- a/upgrading/rosa-upgrading-sts.adoc
+++ b/upgrading/rosa-upgrading-sts.adoc
@@ -11,8 +11,6 @@ toc::[]

 To plan an upgrade, review the xref:../rosa_policy/rosa-life-cycle.adoc#rosa-life-cycle[{product-title} update life cycle]. The life cycle page includes release definitions, support and upgrade requirements, installation policy information and life cycle dates.

-include::modules/rosa-upgrading-preparing-4-7-to-4-8.adoc[leveloffset=+1]
-
 [id="rosa-sts-upgrading-a-cluster-with-sts"]
 == Upgrading a ROSA cluster that uses STS

@@ -27,4 +25,5 @@ For steps to upgrade a ROSA cluster that does not use the AWS Security Token Ser
 ====

 include::modules/rosa-upgrading-cli-tutorial.adoc[leveloffset=+2]
+
 include::modules/rosa-upgrading-manual-ocm.adoc[leveloffset=+2]
--- a/upgrading/rosa-upgrading.adoc
+++ b/upgrading/rosa-upgrading.adoc
@@ -13,17 +13,19 @@ To plan an upgrade, review the xref:../rosa_policy/rosa-life-cycle.adoc#rosa-lif

 [id="rosa-sts-upgrading-a-cluster"]
 == Upgrading a ROSA cluster
-There are three methods to upgrade {product-title} (ROSA) clusters:
-
-* Manual upgrades through the `rosa` CLI
-* Manual upgrades through the {console-redhat-com} console
-* Automatic upgrades through the {console-redhat-com} console

 [NOTE]
 ====
 For steps to upgrade a ROSA cluster that uses the AWS Security Token Service (STS), see xref:../upgrading/rosa-upgrading-sts.adoc#rosa-upgrading-sts[Upgrading ROSA clusters with STS].
 ====

+
+There are three methods to upgrade {product-title} (ROSA) clusters:
+
+* Manual upgrades through the `rosa` CLI
+* Manual upgrades through the {console-redhat-com} console
+* Automatic upgrades through the {console-redhat-com} console
+
 include::modules/rosa-upgrading-cli-tutorial.adoc[leveloffset=+2]
 include::modules/rosa-upgrading-manual-ocm.adoc[leveloffset=+2]
 include::modules/rosa-upgrading-automatic-ocm.adoc[leveloffset=+2]