OSDOCS-6656: Updating for admin-ack for 4.14

Author: bergerhoffer

_topic_maps/_topic_map.yml

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

modules/update-preparing-ack.adoc

@@ -6,7 +6,7 @@
 [id="update-preparing-ack_{context}"]
 = Providing the administrator acknowledgment
 
-After you have evaluated your cluster for any removed APIs and have migrated any removed APIs, you can acknowledge that your cluster is ready to upgrade from {product-title} 4.12 to 4.13.
+After you have evaluated your cluster for any removed APIs and have migrated any removed APIs, you can acknowledge that your cluster is ready to upgrade from {product-title} 4.13 to 4.14.
 
 [WARNING]
 ====
@@ -19,9 +19,9 @@ Be aware that all responsibility falls on the administrator to ensure that all u
 
 .Procedure
 
-* Run the following command to acknowledge that you have completed the evaluation and your cluster is ready for the Kubernetes API removals in {product-title} 4.13:
+* Run the following command to acknowledge that you have completed the evaluation and your cluster is ready for the Kubernetes API removals in {product-title} 4.14:
 +
 [source,terminal]
 ----
-$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.12-kube-1.26-api-removals-in-4.13":"true"}}' --type=merge
+$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-1.27-api-removals-in-4.14":"true"}}' --type=merge
 ----

modules/update-preparing-evaluate-apirequestcount-workloads.adoc

@@ -25,22 +25,23 @@ For example:
 +
 [source,terminal]
 ----
-$ oc get apirequestcounts flowschemas.v1beta1.flowcontrol.apiserver.k8s.io -o yaml
+$ oc get apirequestcounts csistoragecapacities.v1beta1.storage.k8s.io -o yaml
 ----
 +
 You can also use `-o jsonpath` to extract the `username` and `userAgent` values from an `APIRequestCount` resource:
 +
 [source,terminal]
 ----
-$ oc get apirequestcounts flowschemas.v1beta1.flowcontrol.apiserver.k8s.io \
+$ oc get apirequestcounts csistoragecapacities.v1beta1.storage.k8s.io \
   -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
   | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT
 ----
 +
 .Example output
 [source,terminal]
 ----
-VERBS  USERNAME                                                            USERAGENT
-get    system:serviceaccount:openshift-cluster-version:default             cluster-version-operator/v0.0.0
-watch  system:serviceaccount:openshift-oauth-apiserver:oauth-apiserver-sa  oauth-apiserver/v0.0.0
+VERBS       USERNAME                        USERAGENT
+list watch  system:kube-controller-manager  cluster-policy-controller/v0.0.0
+list watch  system:kube-controller-manager  kube-controller-manager/v1.26.5+0abcdef
+list watch  system:kube-scheduler           kube-scheduler/v1.26.5+0abcdef
 ----

modules/update-preparing-evaluate-apirequestcount.adoc

@@ -24,15 +24,12 @@ $ oc get apirequestcounts
 .Example output
 [source,terminal]
 ----
-NAME                                                                      REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
+NAME                                                                 REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
 ...
-flowschemas.v1beta1.flowcontrol.apiserver.k8s.io                          1.26               0                       16
-flowschemas.v1beta2.flowcontrol.apiserver.k8s.io                                             101                     857
-groups.v1.user.openshift.io                                                                  22                      201
-hardwaredata.v1alpha1.metal3.io                                                              3                       33
-helmchartrepositories.v1beta1.helm.openshift.io                                              142                     628
-horizontalpodautoscalers.v2.autoscaling                                                      11                      103
-horizontalpodautoscalers.v2beta2.autoscaling                              1.26               0                       15
+csistoragecapacities.v1.storage.k8s.io                                                  14                      380
+csistoragecapacities.v1beta1.storage.k8s.io                          1.27               0                       16
+custompolicydefinitions.v1beta1.capabilities.3scale.net                                 8                       158
+customresourcedefinitions.v1.apiextensions.k8s.io                                       1407                    30148
 ...
 ----
 +
@@ -54,6 +51,7 @@ $ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease
 .Example output
 [source,terminal]
 ----
-1.26	flowschemas.v1beta1.flowcontrol.apiserver.k8s.io
-1.26	horizontalpodautoscalers.v2beta2.autoscaling
+1.27	csistoragecapacities.v1beta1.storage.k8s.io
+1.29	flowschemas.v1beta2.flowcontrol.apiserver.k8s.io
+1.29	prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io
 ----

modules/update-preparing-list.adoc

@@ -5,24 +5,16 @@
 [id="update-preparing-list_{context}"]
 = Removed Kubernetes APIs
 
-{product-title} 4.13 uses Kubernetes 1.26, which removed the following deprecated APIs. You must migrate manifests and API clients to use the appropriate API version. For more information about migrating removed APIs, see the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-26[Kubernetes documentation].
+{product-title} 4.14 uses Kubernetes 1.27, which removed the following deprecated APIs. You must migrate manifests and API clients to use the appropriate API version. For more information about migrating removed APIs, see the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-27[Kubernetes documentation].
 
-.APIs removed from Kubernetes 1.26
+.APIs removed from Kubernetes 1.27
 [cols="2,2,2",options="header",]
 |===
 |Resource |Removed API |Migrate to
 
-|`FlowSchema`
-|`flowcontrol.apiserver.k8s.io/v1beta1`
-|`flowcontrol.apiserver.k8s.io/v1beta3`
-
-|`HorizontalPodAutoscaler`
-|`autoscaling/v2beta2`
-|`autoscaling/v2`
-
-|`PriorityLevelConfiguration`
-|`flowcontrol.apiserver.k8s.io/v1beta1`
-|`flowcontrol.apiserver.k8s.io/v1beta3`
+|`CSIStorageCapacity`
+|`storage.k8s.io/v1beta1`
+|`storage.k8s.io/v1`
 
 |===
 // Removed the "Notable changes" column since they were all "No" and table so wide it was causing a scrollbar. Add it back in for the next time there are notable changes (1.29)

modules/update-preparing-migrate.adoc

@@ -5,4 +5,4 @@
 [id="update-preparing-migrate_{context}"]
 = Migrating instances of removed APIs
 
-For information about how to migrate removed Kubernetes APIs, see the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-26[Deprecated API Migration Guide] in the Kubernetes documentation.
+For information about how to migrate removed Kubernetes APIs, see the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-27[Deprecated API Migration Guide] in the Kubernetes documentation.

updating/preparing_for_updates/updating-cluster-prepare.adoc

@@ -1,6 +1,6 @@
 :_content-type: ASSEMBLY
 [id="updating-cluster-prepare"]
-= Preparing to update to {product-title} 4.13
+= Preparing to update to {product-title} 4.14
 include::_attributes/common-attributes.adoc[]
 :context: updating-cluster-prepare
 
@@ -12,11 +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.
 ////
 
-{product-title} 4.13 uses Kubernetes 1.26, which removed several deprecated APIs.
+{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.12 to 4.13. This is to help prevent issues after upgrading to {product-title} 4.13, 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.
+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.
 
-Before you can update your {product-title} 4.12 cluster to 4.13, you must provide the administrator acknowledgment.
+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]

updating/updating_a_cluster/updating-cluster-cli.adoc

@@ -29,7 +29,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.26, 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.13].
+* Review the list of APIs that were removed in Kubernetes 1.27, 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.14].
 * 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]

updating/updating_a_cluster/updating-cluster-web-console.adoc

@@ -30,7 +30,7 @@ See xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define an
 //remove this???^ or maybe just add another bullet that you can break up the update?
 * To accommodate the time it takes to update, you are able to do a partial update by updating the worker or custom pool nodes. You can pause and resume within the progress bar of each pool.
 * 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].
-* Review the list of APIs that were removed in Kubernetes 1.26, 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.13].
+* Review the list of APIs that were removed in Kubernetes 1.27, 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.14].
 * 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]