diff --git a/modules/creating-single-etcd-backup.adoc b/modules/creating-single-etcd-backup.adoc index 09ba879620e1..9248ddf02ef6 100644 --- a/modules/creating-single-etcd-backup.adoc +++ b/modules/creating-single-etcd-backup.adoc @@ -32,10 +32,13 @@ spec: - ReadWriteOnce resources: requests: - storage: 200Gi <1> + storage: volumeMode: Filesystem ---- -<1> The amount of storage available to the PVC. Adjust this value for your requirements. ++ +where: ++ +``:: Specifies the amount of storage available to the PVC. Adjust this value for your requirements, such as `200Gi`. + .. Apply the PVC by running the following command: + @@ -73,9 +76,12 @@ metadata: name: etcd-single-backup namespace: openshift-etcd spec: - pvcName: etcd-backup-pvc <1> + pvcName: ---- -<1> The name of the PVC to save the backup to. Adjust this value according to your environment. ++ +where: ++ +``:: Specifies the name of the PVC to save the backup to. Adjust this value according to your environment, such as `etcd-backup-pvc`. + .. Apply the CR to start a single backup: + @@ -115,7 +121,7 @@ metadata: name: etcd-backup-pv-fs spec: capacity: - storage: 100Gi <1> + storage: volumeMode: Filesystem accessModes: - ReadWriteOnce @@ -130,10 +136,13 @@ spec: - key: kubernetes.io/hostname operator: In values: - - <2> + - ---- -<1> The amount of storage available to the PV. Adjust this value for your requirements. -<2> Replace this value with the node to attach this PV to. ++ +where: ++ +``:: Specifies the amount of storage available to the PV. Adjust this value for your requirements, such as `100Gi`. +``:: Specifies the node to attach this PV to. Replace with the actual node name, such as `master-0`. + .. Verify the creation of the PV by running the following command: + @@ -164,9 +173,12 @@ spec: volumeMode: Filesystem resources: requests: - storage: 10Gi <1> + storage: ---- -<1> The amount of storage available to the PVC. Adjust this value for your requirements. ++ +where: ++ +``:: Specifies the amount of storage available to the PVC. Adjust this value for your requirements, such as `10Gi`. + .. Apply the PVC by running the following command: + @@ -185,9 +197,12 @@ metadata: name: etcd-single-backup namespace: openshift-etcd spec: - pvcName: etcd-backup-pvc <1> + pvcName: ---- -<1> The name of the persistent volume claim (PVC) to save the backup to. Adjust this value according to your environment. ++ +where: ++ +``:: Specifies the name of the persistent volume claim (PVC) to save the backup to. Adjust this value according to your environment, such as `etcd-backup-pvc`. + .. Apply the CR to start a single backup: + diff --git a/modules/troubleshooting-general-review-events.adoc b/modules/troubleshooting-general-review-events.adoc index ee2da163912d..17fc43d57683 100644 --- a/modules/troubleshooting-general-review-events.adoc +++ b/modules/troubleshooting-general-review-events.adoc @@ -14,17 +14,19 @@ You can review the events in a given namespace to find potential issues. + [source,terminal] ---- -$ oc get events -n --sort-by=".metadata.creationTimestamp" <1> +$ oc get events -n --sort-by=".metadata.creationTimestamp" ---- -<1> Adding the `--sort-by=".metadata.creationTimestamp"` flag places the most recent events at the end of the output. ++ +The `--sort-by=".metadata.creationTimestamp"` flag places the most recent events at the end of the output. . Optional: If the events within your specified namespace do not provide enough information, expand your query to all namespaces by running the following command: + [source,terminal] ---- -$ oc get events -A --sort-by=".metadata.creationTimestamp" <1> +$ oc get events -A --sort-by=".metadata.creationTimestamp" ---- -<1> The `--sort-by=".metadata.creationTimestamp"` flag places the most recent events at the end of the output. ++ +The `--sort-by=".metadata.creationTimestamp"` flag places the most recent events at the end of the output. + To filter the results of all events from a cluster, you can use the `grep` command. For example, if you are looking for errors, the errors can appear in two different sections of the output: the `TYPE` or `MESSAGE` sections. diff --git a/modules/update-acknowledging-the-update.adoc b/modules/update-acknowledging-the-update.adoc index 40f8c325045d..085f4a7e8006 100644 --- a/modules/update-acknowledging-the-update.adoc +++ b/modules/update-acknowledging-the-update.adoc @@ -10,4 +10,10 @@ When you update to all versions from 4.11 and later, you must manually acknowledge that the update can continue. // Reused in "Acknowledging the Control Plane Only or y-stream update" and "Acknowledging the y-stream release update" sections -include::snippets/acknowledge-the-update.adoc[] \ No newline at end of file +.Prerequisites + +include::snippets/acknowledge-the-update.adoc[] + +.Procedure + +.Verification diff --git a/modules/update-acknowledging-the-y-stream-release-update.adoc b/modules/update-acknowledging-the-y-stream-release-update.adoc index b45039a76f29..792e94fc5cae 100644 --- a/modules/update-acknowledging-the-y-stream-release-update.adoc +++ b/modules/update-acknowledging-the-y-stream-release-update.adoc @@ -11,4 +11,10 @@ When moving between y-stream releases, you must run a patch command to explicitl In the output of the `oc adm upgrade` command, a URL is provided that shows the specific command to run. // Reused in "Acknowledging the Control Plane Only or y-stream update" and "Acknowledging the y-stream release update" sections +.Prerequisites + include::snippets/acknowledge-the-update.adoc[] + +.Procedure + +.Verification diff --git a/modules/update-starting-the-cluster-update.adoc b/modules/update-starting-the-cluster-update.adoc index d011185002c0..bb29f2ecf03f 100644 --- a/modules/update-starting-the-cluster-update.adoc +++ b/modules/update-starting-the-cluster-update.adoc @@ -32,10 +32,12 @@ $ oc adm upgrade --to=4.15.33 * **Z-stream update** - Verify that there are no problems moving to that specific release ==== -.Example output [source,terminal] ---- -Requested update to 4.15.33 <1> +Requested update to ---- -<1> The `Requested update` value changes depending on your particular update. ++ +where: ++ +``:: Specifies the version number for your particular update, such as `4.15.33`. -- diff --git a/modules/update-updating-the-worker-nodes.adoc b/modules/update-updating-the-worker-nodes.adoc index 925ad8d306ea..cb2bc82ec209 100644 --- a/modules/update-updating-the-worker-nodes.adoc +++ b/modules/update-updating-the-worker-nodes.adoc @@ -19,6 +19,8 @@ This is a potential holding point. You can have a cluster version that is fully supported to run in production with the control plane that is updated to a new EUS release while the worker nodes are at a -release. This allows large clusters to upgrade in steps across several maintenance windows. ==== +.Procedure + . You can check how many nodes are managed in an `mcp` group. Run the following command to get the list of `mcp` groups: + diff --git a/post_installation_configuration/day_2_core_cnf_clusters/updating/update-completing-the-control-plane-only-update.adoc b/post_installation_configuration/day_2_core_cnf_clusters/updating/update-completing-the-control-plane-only-update.adoc index c0b7204c8c8e..2ddb6d2885fe 100644 --- a/post_installation_configuration/day_2_core_cnf_clusters/updating/update-completing-the-control-plane-only-update.adoc +++ b/post_installation_configuration/day_2_core_cnf_clusters/updating/update-completing-the-control-plane-only-update.adoc @@ -27,7 +27,7 @@ include::modules/update-starting-the-cluster-update.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources -xref:../../../post_installation_configuration/day_2_core_cnf_clusters/updating/update-api.adoc#update-selecting-the-target-release_update-api[Selecting the target release] +* xref:../../../post_installation_configuration/day_2_core_cnf_clusters/updating/update-api.adoc#update-selecting-the-target-release_update-api[Selecting the target release] include::modules/update-monitoring-the-cluster-update.adoc[leveloffset=+1] diff --git a/snippets/acknowledge-the-update.adoc b/snippets/acknowledge-the-update.adoc index 30cf8b0c00bd..ca0202f5dd04 100644 --- a/snippets/acknowledge-the-update.adoc +++ b/snippets/acknowledge-the-update.adoc @@ -6,13 +6,9 @@ For example, in {product-title} 4.17, there are no API removals. See "Kubernetes API removals" for more information. ==== -.Prerequisites - * You have verified that APIs for all of the applications running on your cluster are compatible with the next Y-stream release of {product-title}. For more details about compatibility, see "Verifying cluster API versions between update versions". -.Procedure - * Complete the administrative acknowledgment to start the cluster update by running the following command: + -- @@ -23,7 +19,6 @@ $ oc adm upgrade If the cluster update does not complete successfully, more details about the update failure are provided in the `Reason` and `Message` sections. -.Example output [source,terminal] ---- Cluster version is 4.15.45 @@ -57,8 +52,6 @@ In this example, a linked Red{nbsp}Hat Knowledgebase article (link:https://acces ==== -- -.Verification - * Verify the update by running the following command: + -- @@ -67,7 +60,6 @@ In this example, a linked Red{nbsp}Hat Knowledgebase article (link:https://acces $ oc get configmap admin-acks -n openshift-config -o json | jq .data ---- -.Example output [source,terminal] ---- {