1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OSDOCS-15935 - Removing unused ROSA assemblies

This commit is contained in:
Olga Tikhomirova
2025-10-03 15:47:14 -07:00
committed by openshift-cherrypick-robot
parent 84e4f29375
commit 7db35630fb
51 changed files with 9 additions and 1616 deletions

View File

@@ -1,37 +0,0 @@
[id="rosa-updating-cluster-prepare"]
= Preparing to upgrade ROSA to 4.9
include::_attributes/common-attributes.adoc[]
ifdef::openshift-dedicated,openshift-rosa[]
include::_attributes/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]

View File

@@ -1,36 +0,0 @@
:_mod-docs-content-type: ASSEMBLY
[id="rosa-upgrading"]
= Upgrading ROSA Classic clusters
include::_attributes/attributes-openshift-dedicated.adoc[]
:context: rosa-upgrading
toc::[]
[id="rosa-lifecycle-policy_{context}"]
== Life cycle policies and planning
To plan an upgrade, review the xref:../rosa_architecture/rosa_policy_service_definition/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.
Upgrades are manually initiated or automatically scheduled. Red Hat Site Reliability Engineers (SREs) monitor upgrade progress and remedy any issues encountered.
[id="rosa-sts-upgrading-a-cluster"]
== Upgrading a ROSA cluster
There are three methods to upgrade {product-title} (ROSA) clusters:
* Individual upgrades through the ROSA CLI (`rosa`)
* Individual upgrades through the {cluster-manager-url}
* Recurring upgrades through the {cluster-manager-url}
[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].
====
[NOTE]
====
When following a scheduled upgrade policy, there might be a delay of an hour or more before the upgrade process begins, even if it is an immediate upgrade. Additionally, the duration of the upgrade might vary based on your workload configuration.
====
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]