Support docs fixes during ROSA review

Michael Burke · Michael Burke · commit 00e9707d78ab · 2023-10-17T16:23:56.000-04:00
diff --git a/modules/cleaning-crio-storage.adoc b/modules/cleaning-crio-storage.adoc
@@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * support/troubleshooting/troubleshooting-crio-issues
+
 :_content-type: PROCEDURE
 [id="cleaning-crio-storage_{context}"]
 
@@ -23,7 +27,7 @@ can't stat lower layer ...  because it does not exist.  Going through storage to
 
 * The container runtime implementation (`crio`) is not working properly.
 
-* You are unable to start a debug shell on the node using `oc debug node/<nodename>` because the container runtime instance (`crio`) is not working.
+* You are unable to start a debug shell on the node using `oc debug node/<node_name>` because the container runtime instance (`crio`) is not working.
 
 Follow this process to completely wipe the CRI-O storage and resolve the errors.
 
@@ -38,19 +42,19 @@ Follow this process to completely wipe the CRI-O storage and resolve the errors.
 [source,terminal]
 +
 ----
-$ oc adm cordon <nodename>
+$ oc adm cordon <node_name>
 ----
 +
 . Drain the node as the cluster-admin user:
 [source,terminal]
 +
 ----
-$ oc adm drain <nodename> --ignore-daemonsets --delete-emptydir-data
+$ oc adm drain <node_name> --ignore-daemonsets --delete-emptydir-data
 ----
 +
 [NOTE]
 ====
-The `terminationGracePeriodSeconds` attribute of a pod or pod template controls the graceful termination period. This attribute defaults at 30 seconds, but can be customized per application as necessary. If set to more than 90 seconds, the pod might be marked as `SIGKILLed` and fail to terminate successfully.
+The `terminationGracePeriodSeconds` attribute of a pod or pod template controls the graceful termination period. This attribute defaults at 30 seconds, but can be customized for each application as necessary. If set to more than 90 seconds, the pod might be marked as `SIGKILLed` and fail to terminate successfully.
 ====
 
 . When the node returns, connect back to the node via SSH or Console. Then connect to the root user:
@@ -125,7 +129,7 @@ ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v
 [source,terminal]
 +
 ----
-$ oc adm uncordon <nodename>
+$ oc adm uncordon <node_name>
 ----
 +
 .Example output
diff --git a/modules/copying-files-pods-and-containers.adoc b/modules/copying-files-pods-and-containers.adoc
@@ -33,7 +33,7 @@ $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  <1>
 +
 [source,terminal]
 ----
-$ oc cp <pod_name>:/<path>  -c <container_name><local_path>  <1>
+$ oc cp <pod_name>:/<path>  -c <container_name> <local_path>  <1>
 ----
 <1> The first container in a pod is selected if the `-c` option is not specified.
 +
diff --git a/modules/gathering-data-audit-logs.adoc b/modules/gathering-data-audit-logs.adoc
@@ -45,7 +45,7 @@ $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 <1>
 ----
 <1> Replace `must-gather-local.472290403699006248` with the actual directory name.
 
-. Attach the compressed file to your support case on the link:https://access.redhat.com[Red Hat Customer Portal].
+. Attach the compressed file to your support case on the link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
 endif::openshift-origin[]
 
 ifeval::["{context}" == "gathering-cluster-data"]
diff --git a/modules/gathering-data-network-logs.adoc b/modules/gathering-data-network-logs.adoc
@@ -26,4 +26,4 @@ $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 <1>
 ----
 <1> Replace `must-gather-local.472290403699006248` with the actual directory name.
 
-. Attach the compressed file to your support case on the link:https://access.redhat.com[Red Hat Customer Portal].
+. Attach the compressed file to your support case on the link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
diff --git a/modules/gathering-data-specific-features.adoc b/modules/gathering-data-specific-features.adoc
@@ -365,7 +365,7 @@ $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ <1>
 <1> Make sure to replace `must-gather-local.5421342344627712289/` with the
 actual directory name.
 
-. Attach the compressed file to your support case on the link:https://access.redhat.com[Red Hat Customer Portal].
+. Attach the compressed file to your support case on the link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
 endif::openshift-origin[]
 
 ifeval::["{context}" == "gathering-cluster-data"]
diff --git a/modules/inspecting-pod-and-container-logs.adoc b/modules/inspecting-pod-and-container-logs.adoc
@@ -42,7 +42,25 @@ Logs retrieved using the preceding `oc logs` commands are composed of messages s
 +
 [source,terminal]
 ----
-$ oc exec <pod_name> ls -alh /var/log
+$ oc exec <pod_name>  -- ls -alh /var/log
+----
++
+.Example output
+[source,text]
+----
+total 124K
+drwxr-xr-x. 1 root root   33 Aug 11 11:23 .
+drwxr-xr-x. 1 root root   28 Sep  6  2022 ..
+-rw-rw----. 1 root utmp    0 Jul 10 10:31 btmp
+-rw-r--r--. 1 root root  33K Jul 17 10:07 dnf.librepo.log
+-rw-r--r--. 1 root root  69K Jul 17 10:07 dnf.log
+-rw-r--r--. 1 root root 8.8K Jul 17 10:07 dnf.rpm.log
+-rw-r--r--. 1 root root  480 Jul 17 10:07 hawkey.log
+-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 lastlog
+drwx------. 2 root root   23 Aug 11 11:14 openshift-apiserver
+drwx------. 2 root root    6 Jul 10 10:31 private
+drwxr-xr-x. 1 root root   22 Mar  9 08:05 rhsm
+-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 wtmp
 ----
 +
 .. Query a specific log file contained in `/var/log` within a pod:
@@ -51,6 +69,19 @@ $ oc exec <pod_name> ls -alh /var/log
 ----
 $ oc exec <pod_name> cat /var/log/<path_to_log>
 ----
++
+.Example output
+[source,text]
+----
+2023-07-10T10:29:38+0000 INFO --- logging initialized ---
+2023-07-10T10:29:38+0000 DDEBUG timer: config: 13 ms
+2023-07-10T10:29:38+0000 DEBUG Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile
+2023-07-10T10:29:38+0000 INFO Updating Subscription Management repositories.
+2023-07-10T10:29:38+0000 INFO Unable to read consumer identity
+2023-07-10T10:29:38+0000 INFO Subscription Manager is operating in container mode.
+2023-07-10T10:29:38+0000 INFO 
+----
++
 .. List log files and subdirectories contained in `/var/log` within a specific container:
 +
 [source,terminal]
diff --git a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc
@@ -48,6 +48,9 @@ $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
 +
 .Example output
 ----
+apiVersion: v1
+kind: Service
+# ...
 spec:
   endpoints:
   - interval: 30s
@@ -56,6 +59,7 @@ spec:
   selector:
     matchLabels:
       app: prometheus-example-app
+# ...
 ----
 +
 [NOTE]
@@ -124,6 +128,7 @@ data:
   config.yaml: |
     prometheusOperator:
       logLevel: debug
+# ...
 ----
 +
 .. Save the file to apply the changes.
diff --git a/modules/olm-cs-status-cli.adoc b/modules/olm-cs-status-cli.adoc
@@ -58,7 +58,12 @@ $ oc describe catalogsource example-catalog -n {global_ns}
 ----
 Name:         example-catalog
 Namespace:    {global_ns}
-...
+Labels:       <none>
+Annotations:  operatorframework.io/managed-by: marketplace-operator
+              target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
+API Version:  operators.coreos.com/v1alpha1
+Kind:         CatalogSource
+# ...
 Status:
   Connection State:
     Address:              example-catalog.{global_ns}.svc:50051
@@ -70,6 +75,7 @@ Status:
     Protocol:           grpc
     Service Name:       example-catalog
     Service Namespace:  {global_ns}
+# ...
 ----
 +
 In the preceding example output, the last observed state is `TRANSIENT_FAILURE`. This state indicates that there is a problem establishing a connection for the catalog source.
diff --git a/modules/olm-status-viewing-cli.adoc b/modules/olm-status-viewing-cli.adoc
@@ -40,12 +40,20 @@ $ oc describe sub <subscription_name> -n <operator_namespace>
 .Example output
 [source,terminal]
 ----
+Name:         cluster-logging
+Namespace:    openshift-logging
+Labels:       operators.coreos.com/cluster-logging.openshift-logging=
+Annotations:  <none>
+API Version:  operators.coreos.com/v1alpha1
+Kind:         Subscription
+# ...
 Conditions:
    Last Transition Time:  2019-07-29T13:42:57Z
    Message:               all available catalogsources are healthy
    Reason:                AllCatalogSourcesHealthy
    Status:                False
    Type:                  CatalogSourcesUnhealthy
+# ...
 ----
 
 [NOTE]
diff --git a/modules/rosa-sts-ocm-role-creation.adoc b/modules/rosa-sts-ocm-role-creation.adoc
@@ -38,16 +38,18 @@ This command allows you create the role by specifying specific attributes. The f
 I: Creating ocm role
 ? Role prefix: ManagedOpenShift <1>
 ? Enable admin capabilities for the OCM role (optional): No <2>
-? Permissions boundary ARN (optional):  <3>
-? Role creation mode: auto <4>
+? Permissions boundary ARN (optional): <3>
+? Role Path (optional): <4>
+? Role creation mode: auto <5>
 I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
-? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes <5>
+? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes <6>
 I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN  'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182'
 I: Linking OCM role
-? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182 <6>
-? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN'? Yes <7>
+? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182 <7>
+? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes <8>
 I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'
 ----
+
 <1> A prefix value for all of the created AWS resources. In this example, `ManagedOpenShift` prepends all of the AWS resources.
 <2> Choose if you want this role to have the additional admin permissions.
 +
@@ -57,7 +59,8 @@ You do not see this prompt if you used the `--admin` option.
 ====
 +
 <3> The Amazon Resource Name (ARN) of the policy to set permission boundaries.
-<4> Choose the method of how to create your AWS roles. Using `auto`, the ROSA CLI generates and links the roles and policies. In the `auto` mode, you receive some different prompts to create the AWS roles.
-<5> The auto method asks if you want to create a specific `ocm-role` using your prefix.
-<6> Confirm that you want to associate your IAM role with your {cluster-manager}.
-<7> Links the created role with your AWS organization.
+<4> Specify an IAM path for the user name.
+<5> Choose the method to create your AWS roles. Using `auto`, the ROSA CLI generates and links the roles and policies. In the `auto` mode, you receive some different prompts to create the AWS roles.
+<6> The `auto` method asks if you want to create a specific `ocm-role` using your prefix.
+<7> Confirm that you want to associate your IAM role with your {cluster-manager}.
+<8> Links the created role with your AWS organization.
diff --git a/modules/rosa-sts-user-role-creation.adoc b/modules/rosa-sts-user-role-creation.adoc
@@ -29,17 +29,19 @@ This command allows you create the role by specifying specific attributes. The f
 I: Creating User role
 ? Role prefix: ManagedOpenShift <1>
 ? Permissions boundary ARN (optional): <2>
-? Role creation mode: auto <3>
+? Role Path (optional): <3>
+? Role creation mode: auto <4>
 I: Creating ocm user role using 'arn:aws:iam::2066:user'
-? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes <4>
+? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes <5>
 I: Created role 'ManagedOpenShift-User.osdocs-Role' with ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role'
 I: Linking User role
 ? User Role ARN: arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role
-? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes <5>
+? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes <6>
 I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'
 ----
 <1> A prefix value for all of the created AWS resources. In this example, `ManagedOpenShift` prepends all of the AWS resources.
 <2> The Amazon Resource Name (ARN) of the policy to set permission boundaries.
-<3> Choose the method of how to create your AWS roles. Using `auto`, the ROSA CLI generates and links the role to your AWS account. In the `auto` mode, you receive some different prompts to create the AWS roles.
-<4> The auto method asks if you want to create a specific `user-role` using your prefix.
-<5> Links the created role with your AWS organization.
+<3> Specify an IAM path for the user name.
+<4> Choose the method to create your AWS roles. Using `auto`, the ROSA CLI generates and links the roles and policies. In the `auto` mode, you receive some different prompts to create the AWS roles.
+<5> The `auto` method asks if you want to create a specific `user-role` using your prefix.
+<6> Links the created role with your AWS organization.
diff --git a/modules/specifying-oc-log-levels.adoc b/modules/specifying-oc-log-levels.adoc
@@ -8,22 +8,37 @@
 
 You can investigate OpenShift CLI (`oc`) issues by increasing the command's log level.
 
+The {product-title} user's current session token is typically included in logged `curl` requests where required. You can also obtain the current user's session token manually, for use when testing aspects of an `oc` command's underlying process step-by-step.
+
 .Prerequisites
 
 * Install the OpenShift CLI (`oc`).
 
 .Procedure
 
-. Specify the `oc` log level when running an `oc` command:
+* Specify the `oc` log level when running an `oc` command:
 +
 [source,terminal]
 ----
-$ oc <options> --loglevel <log_level>
+$ oc <command> --loglevel <log_level>
 ----
++
+where:
++
+--
+<command>:: Specifies the command you are running.
+<log_level>:: Specifies the log level to apply to the command.
+--
 
-. The {product-title} user's current session token is typically included in logged `curl` requests where required. You can also obtain the current user's session token manually, for use when testing aspects of an `oc` command's underlying process step by step:
+* To obtain the current user's session token, run the following command:
 +
 [source,terminal]
 ----
 $ oc whoami -t
 ----
++
+.Example output
+[source,text]
+----
+sha256~RCV3Qcn7H-OEfqCGVI0CvnZ6...
+----
diff --git a/modules/summarizing-cluster-specifications-through-clusterversion.adoc b/modules/summarizing-cluster-specifications-through-clusterversion.adoc
@@ -4,7 +4,7 @@
 
 :_content-type: PROCEDURE
 [id="summarizing-cluster-specifications-through-clusterversion_{context}"]
-= Summarizing cluster specifications through `clusterversion`
+= Summarizing cluster specifications by using a cluster version object
 
 You can obtain a summary of {product-title} cluster specifications by querying the `clusterversion` resource.
 
@@ -26,10 +26,39 @@ endif::openshift-rosa,openshift-dedicated[]
 ----
 $ oc get clusterversion
 ----
-
++
+.Example output
+[source,text]
+----
+NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
+version   4.13.8    True        False         8h      Cluster version is 4.13.8
+----
 . Obtain a detailed summary of cluster specifications, update availability, and update history:
 +
 [source,terminal]
 ----
 $ oc describe clusterversion
 ----
++
+.Example output
+[source,text]
+----
+Name:         version
+Namespace:    
+Labels:       <none>
+Annotations:  <none>
+API Version:  config.openshift.io/v1
+Kind:         ClusterVersion
+# ...
+    Image:    quay.io/openshift-release-dev/ocp-release@sha256:a956488d295fe5a59c8663a4d9992b9b5d0950f510a7387dbbfb8d20fc5970ce
+    URL:      https://access.redhat.com/errata/RHSA-2023:4456
+    Version:  4.13.8
+  History:
+    Completion Time:    2023-08-17T13:20:21Z
+    Image:              quay.io/openshift-release-dev/ocp-release@sha256:a956488d295fe5a59c8663a4d9992b9b5d0950f510a7387dbbfb8d20fc5970ce
+    Started Time:       2023-08-17T12:59:45Z
+    State:              Completed
+    Verified:           false
+    Version:            4.13.8
+# ...
+----
diff --git a/modules/support-collecting-network-trace.adoc b/modules/support-collecting-network-trace.adoc
@@ -125,7 +125,7 @@ $ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-tcpdump-capture
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Transferring a `tcpdump` capture file from a cluster node by using `scp` is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to copy a `tcpdump` capture file from a node by running `scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>`.
 ====
 +
-.. Navigate to an existing support case within link:https://access.redhat.com/support/cases/[https://access.redhat.com/support/cases/].
+.. Navigate to an existing support case within link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
 +
 .. Select *Attach files* and follow the prompts to upload the file.
 
diff --git a/modules/support-gather-data.adoc b/modules/support-gather-data.adoc
@@ -68,7 +68,7 @@ $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ <1>
 <1> Make sure to replace `must-gather-local.5421342344627712289/` with the actual directory name.
 
 ifndef::openshift-origin[]
-. Attach the compressed file to your support case on the link:https://access.redhat.com[Red Hat Customer Portal].
+. Attach the compressed file to your support case on the link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
 endif::[]
 
 ifdef::openshift-origin[]
diff --git a/modules/support-generating-a-sosreport-archive.adoc b/modules/support-generating-a-sosreport-archive.adoc
@@ -130,6 +130,6 @@ $ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-clust
 {product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Transferring a `sosreport` archive from a cluster node by using `scp` is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to copy a `sosreport` archive from a node by running `scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>`.
 ====
 +
-.. Navigate to an existing support case within link:https://access.redhat.com/support/cases/[https://access.redhat.com/support/cases/].
+.. Navigate to an existing support case within link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
 +
 .. Select *Attach files* and follow the prompts to upload the file.
diff --git a/modules/support-get-cluster-id.adoc b/modules/support-get-cluster-id.adoc
@@ -31,7 +31,7 @@ ifdef::openshift-origin[]
 endif::[]
 
 * To manually obtain your cluster ID using the web console:
-.. Navigate to *Home* -> *Dashboards* -> *Overview*.
+.. Navigate to *Home* -> *Overview*.
 .. The value is available in the *Cluster ID* field of the *Details* section.
 
 * To obtain your cluster ID using the OpenShift CLI (`oc`), run the following command:
diff --git a/modules/support-knowledgebase-search.adoc b/modules/support-knowledgebase-search.adoc
diff --git a/modules/support-providing-diagnostic-data-to-red-hat.adoc b/modules/support-providing-diagnostic-data-to-red-hat.adoc
diff --git a/modules/support-submitting-a-case.adoc b/modules/support-submitting-a-case.adoc
diff --git a/modules/troubleshooting-disabling-autoreboot-mco-console.adoc b/modules/troubleshooting-disabling-autoreboot-mco-console.adoc

Original file line number	Diff line number	Diff line change
`@@ -33,7 +33,7 @@ $ oc cp <local_path> <pod_name>:/<path> -c <container_name> <1>`
`33`	`33`	`+`
`34`	`34`	`[source,terminal]`
`35`	`35`	`----`
`36`		`-$ oc cp <pod_name>:/<path> -c <container_name><local_path> <1>`
	`36`	`+$ oc cp <pod_name>:/<path> -c <container_name> <local_path> <1>`
`37`	`37`	`----`
`38`	`38`	<1> The first container in a pod is selected if the `-c` option is not specified.
`39`	`39`	`+`