Skip to content

TELCODOCS-2708 DITA migration cleanup for update-completing-the-control-plane-only-update.adoc #111653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lcavalle wants to merge 1 commit into
base: main
Choose a base branch
from
Open

TELCODOCS-2708 DITA migration cleanup for update-completing-the-control-plane-only-update.adoc #111653

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 27 additions & 12 deletions modules/creating-single-etcd-backup.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,10 +32,13 @@ spec:
- ReadWriteOnce
resources:
requests:
storage: 200Gi <1>
storage: <storage_amount>
volumeMode: Filesystem
----
<1> The amount of storage available to the PVC. Adjust this value for your requirements.
+
where:
+
`<storage_amount>`:: 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:
+
Expand Down Expand Up @@ -73,9 +76,12 @@ metadata:
name: etcd-single-backup
namespace: openshift-etcd
spec:
pvcName: etcd-backup-pvc <1>
pvcName: <pvc_name>
----
<1> The name of the PVC to save the backup to. Adjust this value according to your environment.
+
where:
+
`<pvc_name>`:: 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:
+
Expand Down Expand Up @@ -115,7 +121,7 @@ metadata:
name: etcd-backup-pv-fs
spec:
capacity:
storage: 100Gi <1>
storage: <storage_amount>
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
Expand All @@ -130,10 +136,13 @@ spec:
- key: kubernetes.io/hostname
operator: In
values:
- <example_master_node> <2>
- <node_name>
----
<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:
+
`<storage_amount>`:: Specifies the amount of storage available to the PV. Adjust this value for your requirements, such as `100Gi`.
`<node_name>`:: 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:
+
Expand Down Expand Up @@ -164,9 +173,12 @@ spec:
volumeMode: Filesystem
resources:
requests:
storage: 10Gi <1>
storage: <storage_amount>
----
<1> The amount of storage available to the PVC. Adjust this value for your requirements.
+
where:
+
`<storage_amount>`:: 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:
+
Expand All @@ -185,9 +197,12 @@ metadata:
name: etcd-single-backup
namespace: openshift-etcd
spec:
pvcName: etcd-backup-pvc <1>
pvcName: <pvc_name>
----
<1> The name of the persistent volume claim (PVC) to save the backup to. Adjust this value according to your environment.
+
where:
+
`<pvc_name>`:: 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:
+
Expand Down
10 changes: 6 additions & 4 deletions modules/troubleshooting-general-review-events.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,17 +14,19 @@ You can review the events in a given namespace to find potential issues.
+
[source,terminal]
----
$ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp" <1>
$ oc get events -n <namespace> --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.
Expand Down
8 changes: 7 additions & 1 deletion modules/update-acknowledging-the-update.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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[]
.Prerequisites

include::snippets/acknowledge-the-update.adoc[]

.Procedure

.Verification
6 changes: 6 additions & 0 deletions modules/update-acknowledging-the-y-stream-release-update.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
8 changes: 5 additions & 3 deletions modules/update-starting-the-cluster-update.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <version>
----
<1> The `Requested update` value changes depending on your particular update.
+
where:
+
`<version>`:: Specifies the version number for your particular update, such as `4.15.33`.
--
2 changes: 2 additions & 0 deletions modules/update-updating-the-worker-nodes.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <y-2>-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:
+
Expand Down
2 changes: 1 addition & 1 deletion ...core_cnf_clusters/updating/update-completing-the-control-plane-only-update.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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]

Expand Down
8 changes: 0 additions & 8 deletions snippets/acknowledge-the-update.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
+
--
Expand All @@ -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
Expand Down Expand Up @@ -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:
+
--
Expand All @@ -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]
----
{
Expand Down