openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 21:46:22 +01:00
Code Issues Releases Activity

Merge pull request #64646 from skopacz1/OSDOCS-7103

Browse Source 
OSDOCS#7103: adding admin guideline for conditional updates
This commit is contained in:
Ϳason Βoxman
2023-09-15 11:11:04 -04:00
committed by GitHub
parent 018afad720 4f1e8a9146
commit f38fd03a56
2 changed files with 41 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
modules/update-preparing-conditional.adoc Normal file
View File

@@ -0,0 +1,22 @@
// Module included in the following assemblies:
//
// * updating/preparing_for_updates/updating-cluster-prepare.adoc
:_content-type: PROCEDURE
[id="update-preparing-conditional_{context}"]
= Assessing the risk of conditional updates
A _conditional update_ is an update target that is available but not recommended due to a known risk that applies to your cluster.
The Cluster Version Operator (CVO) periodically queries the OpenShift Update Service (OSUS) for the most recent data about update recommendations, and some potential update targets might have risks associated with them.
The CVO evaluates the conditional risks, and if the risks are not applicable to the cluster, then the target version is available as a recommended update path for the cluster.
If the risk is determined to be applicable, or if for some reason CVO cannot evaluate the risk, then the update target is available to the cluster as a conditional update.
When you encounter a conditional update while you are trying to update to a target version, you must assess the risk of updating your cluster to that version.
Generally, if you do not have a specific need to update to that target version, it is best to wait for a recommended update path from Red Hat.
However, if you have a strong reason to update to that version, for example, if you need to fix an important CVE, then the benefit of fixing the CVE might outweigh the risk of the update being problematic for your cluster.
You can complete the following tasks to determine whether you agree with the Red Hat assessment of the update risk:
* Complete extensive testing in a non-production environment to the extent that you are comfortable completing the update in your production environment.
* Follow the links provided in the conditional update description, investigate the bug, and determine if it is likely to cause issues for your cluster. If you need help understanding the risk, contact Red Hat Support.

26
updating/preparing_for_updates/updating-cluster-prepare.adoc
View File

@@ -12,6 +12,11 @@ WARNING: This assembly has been moved into a subdirectory for 4.14+. Changes to
To do: Remove this comment once 4.13 docs are EOL.
////
Learn more about administrative tasks that cluster admins must perform to successfully initialize an update, as well as optional guidelines for ensuring a successful update.
[id="kube-api-removals_{context}"]
== Kubernetes API deprecations and removals
{product-title} 4.14 uses Kubernetes 1.27, which removed several deprecated APIs.
A cluster administrator must provide a manual acknowledgment before the cluster can be updated from {product-title} 4.13 to 4.14. This is to help prevent issues after upgrading to {product-title} 4.14, 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.
@@ -19,24 +24,31 @@ A cluster administrator must provide a manual acknowledgment before the cluster
Before you can update your {product-title} 4.13 cluster to 4.14, you must provide the administrator acknowledgment.
// Removed Kubernetes APIs
include::modules/update-preparing-list.adoc[leveloffset=+1]
include::modules/update-preparing-list.adoc[leveloffset=+2]
[id="evaluating-cluster-removed-apis"]
== Evaluating your cluster for 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]
include::modules/update-preparing-evaluate-alerts.adoc[leveloffset=+3]
// Using APIRequestCount to identify uses of removed APIs
include::modules/update-preparing-evaluate-apirequestcount.adoc[leveloffset=+2]
include::modules/update-preparing-evaluate-apirequestcount.adoc[leveloffset=+3]
// Using APIRequestCount to identify which workloads are using the removed APIs
include::modules/update-preparing-evaluate-apirequestcount-workloads.adoc[leveloffset=+2]
include::modules/update-preparing-evaluate-apirequestcount-workloads.adoc[leveloffset=+3]
// Migrating instances of removed APIs
include::modules/update-preparing-migrate.adoc[leveloffset=+1]
include::modules/update-preparing-migrate.adoc[leveloffset=+2]
// Providing the administrator acknowledgment
include::modules/update-preparing-ack.adoc[leveloffset=+1]
include::modules/update-preparing-ack.adoc[leveloffset=+2]
// Assessing the risk of conditional updates
include::modules/update-preparing-conditional.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../../updating/understanding_updates/how-updates-work.adoc#update-evaluate-availability_how-updates-work[Evaluation of update availability]