Skip to content

Commit 89b31fd

Browse files
bergerhofferbergerhoffer
authored
Merge pull request #20398 from bergerhoffer/OSDOCS-878-44
OSDOCS-957: Updating restart requirements due to auto rotation for 4.4
2 parents d274a5c + 0e7c910 commit 89b31fd

File tree

6 files changed

+9
-77
lines changed

6 files changed

+9
-77
lines changed

‎modules/update-upgrading-cli.adoc‎

Lines changed: 0 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -145,19 +145,3 @@ $ oc get clusterversion
145145
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
146146
version 4.1.2 True False 2m Cluster version is 4.1.2
147147
----
148-
149-
. 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:
150-
+
151-
----
152-
$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
153-
do oc delete pods --all -n $I; \
154-
sleep 1; \
155-
done
156-
----
157-
+
158-
[NOTE]
159-
====
160-
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.
161-
162-
After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
163-
====

‎modules/update-upgrading-web.adoc‎

Lines changed: 5 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -63,15 +63,8 @@ and click *Update*.
6363
The *UPDATE STATUS* changes to `Updating`, and you can review the progress of
6464
the Operator upgrades on the *Cluster Operators* tab.
6565

66-
. If you are upgrading to this release from {product-title}
67-
ifdef::within[]
68-
4.3.3 or earlier,
69-
endif::within[]
7066
ifdef::between[]
71-
// 4.2.16 or earlier,
72-
4.2,
73-
endif::between[]
74-
you must restart all Pods after the upgrade is complete. You can do this using the following command, which requires the OpenShift CLI (`oc`):
67+
. 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`):
7568
+
7669
----
7770
$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
@@ -82,18 +75,13 @@ $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {en
8275
+
8376
[NOTE]
8477
====
85-
Restarting all Pods is required because the service CA is automatically rotated as of {product-title}
86-
ifdef::within[]
87-
4.3.5.
88-
endif::within[]
89-
ifdef::between[]
90-
// 4.2.18 and 4.3.5.
91-
4.3.5.
92-
endif::between[]
93-
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.
78+
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.
9479
9580
After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
9681
====
82+
+
83+
// TODO: This whole step should be removed for 4.5.
84+
endif::between[]
9785

9886
ifdef::between[]
9987
. 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‎

Lines changed: 2 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -18,15 +18,10 @@ Because of the difficulty of changing update channels by using `oc`, use the web
1818
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
1919
* 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].
2020

21-
// The following note will need to stay until (and be updated for) the 4.4 docs
22-
23-
// Assuming next z-streams:
24-
// from {product-title} 4.1.31 or earlier; as of {product-title} 4.1.34
25-
// from {product-title} 4.2.16 or earlier; as of {product-title} 4.2.18 and 4.3.5
26-
21+
// The following note should be removed for 4.5.
2722
[IMPORTANT]
2823
====
29-
If you are upgrading to this release from {product-title} 4.2, you must restart all Pods after the upgrade is complete.
24+
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.
3025
3126
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.
3227

‎updating/updating-cluster-cli.adoc‎

Lines changed: 0 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -13,21 +13,6 @@ You can update, or upgrade, an {product-title} cluster within a minor version by
1313
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
1414
* 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].
1515

16-
// The following note should not be needed come 4.4 docs
17-
18-
// Assuming next z-streams:
19-
// from {product-title} 4.1.31 or earlier; as of {product-title} 4.1.34
20-
// from {product-title} 4.2.16 or earlier; as of {product-title} 4.2.18
21-
22-
[IMPORTANT]
23-
====
24-
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.
25-
26-
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.
27-
28-
After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
29-
====
30-
3116
include::modules/update-service-overview.adoc[leveloffset=+1]
3217

3318
include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]

‎updating/updating-cluster-rhel-compute.adoc‎

Lines changed: 2 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -15,15 +15,10 @@ those machines.
1515
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
1616
* 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].
1717

18-
// The following note will need to stay until (and be updated for) the 4.4 docs
19-
20-
// Assuming next z-streams:
21-
// from {product-title} 4.1.31 or earlier; as of {product-title} 4.1.34
22-
// from {product-title} 4.2.16 or earlier; as of {product-title} 4.2.18 and 4.3.5
23-
18+
// TODO: The following note should be removed for 4.5.
2419
[IMPORTANT]
2520
====
26-
If you are upgrading to this release from {product-title} 4.2, you must restart all Pods after the upgrade is complete.
21+
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.
2722
2823
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.
2924

‎updating/updating-cluster.adoc‎

Lines changed: 0 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -13,21 +13,6 @@ You can update, or upgrade, an {product-title} cluster by using the web console.
1313
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
1414
* 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].
1515

16-
// The following note should not be needed come 4.4 docs
17-
18-
// Assuming next z-streams:
19-
// from {product-title} 4.1.31 or earlier; as of {product-title} 4.1.34
20-
// from {product-title} 4.2.16 or earlier; as of {product-title} 4.2.18
21-
22-
[IMPORTANT]
23-
====
24-
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.
25-
26-
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.
27-
28-
After this one-time manual restart, subsequent upgrades and rotations will ensure restart before the service CA expires without requiring manual intervention.
29-
====
30-
3116
include::modules/update-service-overview.adoc[leveloffset=+1]
3217

3318
include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]

0 commit comments

Comments
 (0)