Merge pull request #22360 from bergerhoffer/OSDOCS-1100-rmv-restart

OSDOCS-1100: Removing manual restart requirement for 4.5

Author: bergerhoffer

modules/update-upgrading-web.adoc

@@ -63,26 +63,6 @@ and click *Update*.
 The *UPDATE STATUS* changes to `Updating`, and you can review the progress of
 the Operator upgrades on the *Cluster Operators* tab.
 
-ifdef::between[]
-. If you are upgrading to this release from {product-title} 4.3.3 or earlier, you must restart all Pods after the upgrade is complete. You can do this using the following command, which requires the OpenShift CLI (`oc`):
-+
-----
-$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
-      do oc delete pods --all -n $I; \
-      sleep 1; \
-      done
-----
-+
-[NOTE]
-====
-Restarting all Pods is required because the service CA is automatically rotated as of {product-title} 4.3.5. The service CA is rotated during the upgrade and a restart is required afterward to ensure that all services are using the new service CA before the previous service CA expires.
-
-After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
-====
-+
-// TODO: This whole step should be removed for 4.5.
-endif::between[]
-
 ifdef::between[]
 . After the update completes and the Cluster Version Operator refreshes the available updates, check if more updates are available in your current channel.
 +

updating/updating-cluster-between-minor.adoc

@@ -18,16 +18,6 @@ Because of the difficulty of changing update channels by using `oc`, use the web
 See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
 * Have a recent xref:../backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
 
-// The following note should be removed for 4.5.
-[IMPORTANT]
-====
-If you are upgrading to this release from {product-title} 4.3.3 or earlier, you must restart all Pods after the upgrade is complete.
-
-This is because the service CA is automatically rotated as of {product-title} 4.3.5. The service CA is rotated during the upgrade and a restart is required afterward to ensure that all services are using the new service CA before the previous service CA expires.
-
-After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
-====
-
 include::modules/update-service-overview.adoc[leveloffset=+1]
 .Additional resources
 

updating/updating-cluster-rhel-compute.adoc

@@ -15,16 +15,6 @@ those machines.
 See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
 * Have a recent xref:../backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
 
-// TODO: The following note should be removed for 4.5.
-[IMPORTANT]
-====
-If you are upgrading to this release from {product-title} 4.3.3 or earlier, you must restart all Pods after the upgrade is complete.
-
-This is because the service CA is automatically rotated as of {product-title} 4.3.5. The service CA is rotated during the upgrade and a restart is required afterward to ensure that all services are using the new service CA before the previous service CA expires.
-
-After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
-====
-
 include::modules/update-service-overview.adoc[leveloffset=+1]
 .Additional resources