OSDOCS#11574: Updating for no Kubernetes API removals in OCP 4.17

_topic_maps/_topic_map.yml

@@ -677,10 +677,10 @@ Topics:
 - Name: Preparing to update a cluster
   Dir: preparing_for_updates
   Topics:
-  - Name: Preparing to update to OpenShift Container Platform 4.16
+  - Name: Preparing to update to OpenShift Container Platform 4.17
     File: updating-cluster-prepare
     Distros: openshift-enterprise
-  - Name: Preparing to update to OKD 4.16
+  - Name: Preparing to update to OKD 4.17
     File: updating-cluster-prepare
     Distros: openshift-origin
   - Name: Preparing to update a cluster with manually maintained credentials

updating/preparing_for_updates/updating-cluster-prepare.adoc

@@ -27,6 +27,10 @@ Without the correct micro-architecture requirements, the update process will fai
 [id="kube-api-removals_{context}"]
 == Kubernetes API removals
 
+There are no Kubernetes API removals in {product-title} 4.17.
+
+// Commenting out this section because there are no APIs being removed in OCP 4.17 / Kube 1.30. But we'll need this section again for OCP 4.19 / Kube 1.32
+////
 {product-title} 4.16 uses Kubernetes 1.29, which removed several deprecated APIs.
 
 A cluster administrator must provide a manual acknowledgment before the cluster can be updated from {product-title} 4.15 to 4.16. This is to help prevent issues after upgrading to {product-title} 4.16, 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.
@@ -55,6 +59,7 @@ include::modules/update-preparing-migrate.adoc[leveloffset=+2]
 
 // Providing the administrator acknowledgment
 include::modules/update-preparing-ack.adoc[leveloffset=+2]
+////
 
 // Assessing the risk of conditional updates
 include::modules/update-preparing-conditional.adoc[leveloffset=+1]

updating/updating_a_cluster/updating-cluster-cli.adoc

@@ -30,7 +30,7 @@ See xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define an
 * Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
 * If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see xref:../../updating/preparing_for_updates/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials].
 * Ensure that you address all `Upgradeable=False` conditions so the cluster allows an update to the next minor version. An alert displays at the top of the *Cluster Settings* page when you have one or more cluster Operators that cannot be updated. You can still update to the next available patch update for the minor release you are currently on.
-* Review the list of APIs that were removed in Kubernetes 1.28, migrate any affected components to use the new API version, and provide the administrator acknowledgment. For more information, see xref:../../updating/preparing_for_updates/updating-cluster-prepare.adoc#updating-cluster-prepare[Preparing to update to {product-title} 4.16].
+// * Review the list of APIs that were removed in Kubernetes 1.28, migrate any affected components to use the new API version, and provide the administrator acknowledgment. For more information, see xref:../../updating/preparing_for_updates/updating-cluster-prepare.adoc#updating-cluster-prepare[Preparing to update to {product-title} 4.16].
 * If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the update process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
 
 [IMPORTANT]