diff --git a/_topic_maps/_topic_map_osd.yml b/_topic_maps/_topic_map_osd.yml index 0f9648b78d..21c9c62aac 100644 --- 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 diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml index 8a73c837d3..b99b3fcfb7 100644 --- 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 diff --git a/modules/osd-update-preparing-evaluate-alerts.adoc b/modules/osd-update-preparing-evaluate-alerts.adoc new file mode 100644 index 0000000000..9a4152dee1 --- /dev/null +++ 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. diff --git a/modules/osd-update-preparing-evaluate-apirequestcount-workloads.adoc b/modules/osd-update-preparing-evaluate-apirequestcount-workloads.adoc new file mode 100644 index 0000000000..676cc0972d --- /dev/null +++ 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 .. -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 +---- diff --git a/modules/osd-update-preparing-evaluate-apirequestcount.adoc b/modules/osd-update-preparing-evaluate-apirequestcount.adoc new file mode 100644 index 0000000000..1b6b32e72f --- /dev/null +++ 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 +---- diff --git a/modules/osd-update-preparing-list.adoc b/modules/osd-update-preparing-list.adoc new file mode 100644 index 0000000000..3bd4866a34 --- /dev/null +++ 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 + +|=== diff --git a/modules/osd-update-preparing-migrate.adoc b/modules/osd-update-preparing-migrate.adoc new file mode 100644 index 0000000000..12c4b5aa18 --- /dev/null +++ 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. diff --git a/modules/rosa-upgrading-cli-tutorial.adoc b/modules/rosa-upgrading-cli-tutorial.adoc index 0105feb4e1..8086d50518 100644 --- 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 diff --git a/modules/rosa-upgrading-manual-ocm.adoc b/modules/rosa-upgrading-manual-ocm.adoc index 2724bedfd8..85278cacdf 100644 --- 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*. diff --git a/modules/rosa-upgrading-preparing-4-7-to-4-8.adoc b/modules/rosa-upgrading-preparing-4-7-to-4-8.adoc index 5e74ebd8df..01027bc820 100644 --- 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. diff --git a/modules/rosa-upgrading-preparing-4-8-to-4-9.adoc b/modules/rosa-upgrading-preparing-4-8-to-4-9.adoc new file mode 100644 index 0000000000..17d024c7a9 --- /dev/null +++ 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. diff --git a/modules/upgrade-49-acknowledgement.adoc b/modules/upgrade-49-acknowledgement.adoc new file mode 100644 index 0000000000..2e2f51c09c --- /dev/null +++ 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. diff --git a/updating/updating-cluster-prepare.adoc b/updating/updating-cluster-prepare.adoc new file mode 100644 index 0000000000..ff4f236782 --- /dev/null +++ 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] diff --git a/upgrading/osd-upgrading-cluster-prepare.adoc b/upgrading/osd-upgrading-cluster-prepare.adoc new file mode 100644 index 0000000000..b0517b988b --- /dev/null +++ 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] diff --git a/upgrading/rosa-upgrading-cluster-prepare.adoc b/upgrading/rosa-upgrading-cluster-prepare.adoc new file mode 100644 index 0000000000..7d71ef7ff7 --- /dev/null +++ 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] diff --git a/upgrading/rosa-upgrading-sts.adoc b/upgrading/rosa-upgrading-sts.adoc index 07a27a1918..8cfce69113 100644 --- 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] diff --git a/upgrading/rosa-upgrading.adoc b/upgrading/rosa-upgrading.adoc index 0cdf4331a8..a6500c0276 100644 --- 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]