Nodes Containers docs fixes during ROSA review

Author: Michael Burke

modules/nodes-cluster-enabling-features-cli.adoc

@@ -36,6 +36,7 @@ apiVersion: config.openshift.io/v1
 kind: FeatureGate
 metadata:
   name: cluster <1>
+# ...
 spec:
   featureSet: TechPreviewNoUpgrade <2>
 ----

modules/nodes-cluster-enabling-features-console.adoc

@@ -35,8 +35,7 @@ apiVersion: config.openshift.io/v1
 kind: FeatureGate
 metadata:
   name: cluster <1>
-....
-
+# ...
 spec:
   featureSet: TechPreviewNoUpgrade <2>
 ----

modules/nodes-cluster-worker-latency-profiles-using.adoc

@@ -57,41 +57,11 @@ metadata:
 spec:
   workerLatencyProfile: MediumUpdateAverageReaction <1>
 
- ...
+# ...
 ----
 <1> Specifies the medium worker latency policy.
 +
 Scheduling on each worker node is disabled as the change is being applied.
-+
-When all nodes return to the `Ready` condition, you can use the following command to look in the Kubernetes Controller Manager to ensure it was applied:
-+
-[source,terminal]
-----
-$ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
-----
-+
-.Example output
-[source,terminal]
-----
- ...
-    - lastTransitionTime: "2022-07-11T19:47:10Z"
-      reason: ProfileUpdated
-      status: "False"
-      type: WorkerLatencyProfileProgressing
-    - lastTransitionTime: "2022-07-11T19:47:10Z" <1>
-      message: all static pod revision(s) have updated latency profile
-      reason: ProfileUpdated
-      status: "True"
-      type: WorkerLatencyProfileComplete
-    - lastTransitionTime: "2022-07-11T19:20:11Z"
-      reason: AsExpected
-      status: "False"
-      type: WorkerLatencyProfileDegraded
-    - lastTransitionTime: "2022-07-11T19:20:36Z"
-      status: "False"
- ...
-----
-<1> Specifies that the profile is applied and active.
 
 . Optional: Move to the low worker latency profile:
 
@@ -128,11 +98,43 @@ metadata:
 spec:
   workerLatencyProfile: LowUpdateSlowReaction <1>
 
- ...
+# ...
 ----
 <1> Specifies to use the low worker latency policy.
 +
 Scheduling on each worker node is disabled as the change is being applied.
 
+.Verification
+
+* When all nodes return to the `Ready` condition, you can use the following command to look in the Kubernetes Controller Manager to ensure it was applied:
++
+[source,terminal]
+----
+$ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
+----
++
+.Example output
+[source,terminal]
+----
+# ...
+    - lastTransitionTime: "2022-07-11T19:47:10Z"
+      reason: ProfileUpdated
+      status: "False"
+      type: WorkerLatencyProfileProgressing
+    - lastTransitionTime: "2022-07-11T19:47:10Z" <1>
+      message: all static pod revision(s) have updated latency profile
+      reason: ProfileUpdated
+      status: "True"
+      type: WorkerLatencyProfileComplete
+    - lastTransitionTime: "2022-07-11T19:20:11Z"
+      reason: AsExpected
+      status: "False"
+      type: WorkerLatencyProfileDegraded
+    - lastTransitionTime: "2022-07-11T19:20:36Z"
+      status: "False"
+# ...
+----
+<1> Specifies that the profile is applied and active.
+
 To change the low profile to medium or change the medium to low, edit the `node.config` object and set the `spec.workerLatencyProfile` parameter to the appropriate value.
 

modules/nodes-containers-copying-files-about.adoc

@@ -19,15 +19,15 @@ $ oc rsync <source> <destination> [-c <container>]
 Specifying the Copy Source::
 The source argument of the `oc rsync` command must point to either a local
 directory or a pod directory. Individual files are not supported.
-
++
 When specifying a pod directory the directory name must be prefixed with the pod
 name:
-
++
 [source,terminal]
 ----
 <pod name>:<dir>
 ----
-
++
 If the directory name ends in a path separator (`/`), only the contents of the directory are copied to the destination. Otherwise, the
 directory and its contents are copied to the destination.
 
@@ -44,11 +44,11 @@ Continuous Syncing on File Change::
 Using the `--watch` option causes the command to monitor the source path for any
 file system changes, and synchronizes changes when they occur. With this
 argument, the command runs forever.
-
++
 Synchronization occurs after short quiet periods to ensure a
 rapidly changing file system does not result in continuous synchronization
 calls.
-
++
 When using the `--watch` option, the behavior is effectively the same as
 manually invoking `oc rsync` repeatedly, including any arguments normally passed
 to `oc rsync`. Therefore, you can control the behavior via the same flags used

modules/nodes-containers-copying-files-procedure.adoc

@@ -12,19 +12,18 @@ Support for copying local files to or from a container is built into the CLI.
 
 When working with `oc rsync`, note the following:
 
-rsync must be installed::
-The `oc rsync` command uses the local `rsync` tool if present on the client
+* rsync must be installed. The `oc rsync` command uses the local `rsync` tool, if present on the client
 machine and the remote container.
-
++
 If `rsync` is not found locally or in the remote container, a *tar* archive
 is created locally and sent to the container where the *tar* utility is used to
 extract the files. If *tar* is not available in the remote container, the
 copy will fail.
-
++
 The *tar* copy method does not provide the same functionality as `oc rsync`. For
 example, `oc rsync` creates the destination directory if it does not exist and
 only sends files that are different between the source and the destination.
-
++
 [NOTE]
 ====
 In Windows, the `cwRsync` client should be installed and added to the PATH for

modules/nodes-containers-copying-files-rsync.adoc

@@ -13,7 +13,7 @@ environment variable as a workaround, as follows:
 
 [source,terminal]
 ----
-$ rsync --rsh='oc rsh' --exclude-from=FILE SRC POD:DEST
+$ rsync --rsh='oc rsh' --exclude-from=<file_name> <local-dir> <pod-name>:/<remote-dir>
 ----
 
 or:
@@ -29,7 +29,7 @@ Then, run the rsync command:
 
 [source,terminal]
 ----
-$ rsync --exclude-from=FILE SRC POD:DEST
+$ rsync --exclude-from=<file_name> <local-dir> <pod-name>:/<remote-dir>
 ----
 
 Both of the above examples configure standard `rsync` to use `oc rsh` as its

modules/nodes-containers-downward-api-container-configmaps.adoc

@@ -11,7 +11,9 @@ so image and application authors can create an image for specific environments.
 
 .Procedure
 
-. Create a `*_configmap.yaml_*` file:
+. Create a config map with the values to inject:
+
+.. Create a `*_configmap.yaml_*` file similar to the following:
 +
 [source,yaml]
 ----
@@ -23,14 +25,16 @@ data:
   mykey: myvalue
 ----
 
-. Create a `ConfigMap` object from the `*_configmap.yaml_*` file:
+.. Create the config map from the `configmap.yaml` file:
 +
 [source,terminal]
 ----
 $ oc create -f configmap.yaml
 ----
 
-. Create a `*_pod.yaml_*` file that references the above `ConfigMap` object:
+. Create a pod that references the above config map:
+
+.. Create a `pod.yaml` file similar to the following:
 +
 [source,yaml]
 ----
@@ -50,16 +54,19 @@ spec:
               name: myconfigmap
               key: mykey
   restartPolicy: Always
+# ...
 ----
 
-. Create the pod from the `*_pod.yaml_*` file:
+.. Create the pod from the `pod.yaml` file:
 +
 [source,terminal]
 ----
 $ oc create -f pod.yaml
 ----
 
-. Check the container's logs for the `MY_CONFIGMAP_VALUE` value:
+.Verification
+
+* Check the container's logs for the `MY_CONFIGMAP_VALUE` value:
 +
 [source,terminal]
 ----

modules/nodes-containers-downward-api-container-envars.adoc

@@ -13,7 +13,9 @@ string.
 
 .Procedure
 
-. Create a `*_pod.yaml_*` file that references an existing `environment variable`:
+. Create a pod that references an existing environment variable:
+
+.. Create a `pod.yaml` file similar to the following:
 +
 [source,yaml]
 ----
@@ -32,16 +34,19 @@ spec:
         - name: MY_ENV_VAR_REF_ENV
           value: $(MY_EXISTING_ENV)
   restartPolicy: Never
+# ...
 ----
 
-. Create the pod from the `*_pod.yaml_*` file:
+.. Create the pod from the `*_pod.yaml_*` file:
 +
 [source,terminal]
 ----
 $ oc create -f pod.yaml
 ----
 
-. Check the container's logs for the `MY_ENV_VAR_REF_ENV` value:
+.Verification
+
+* Check the container's logs for the `MY_ENV_VAR_REF_ENV` value:
 +
 [source,terminal]
 ----

modules/nodes-containers-downward-api-container-escaping.adoc

@@ -12,7 +12,9 @@ of the provided value.
 
 .Procedure
 
-. Create a `*_pod.yaml_*` file that references an existing `environment variable`:
+. Create a pod that references an existing environment variable:
+
+.. Create a `pod.yaml` file similar to the following:
 +
 [source,yaml]
 ----
@@ -29,16 +31,19 @@ spec:
         - name: MY_NEW_ENV
           value: $$(SOME_OTHER_ENV)
   restartPolicy: Never
+# ...
 ----
 
-. Create the pod from the `*_pod.yaml_*` file:
+.. Create the pod from the `*_pod.yaml_*` file:
 +
 [source,terminal]
 ----
 $ oc create -f pod.yaml
 ----
 
-. Check the container's logs for the `MY_NEW_ENV` value:
+.Verification
+
+* Check the container's logs for the `MY_NEW_ENV` value:
 +
 [source,terminal]
 ----

modules/nodes-containers-downward-api-container-resources-envars.adoc

@@ -9,17 +9,28 @@
 When creating pods, you can use the Downward API to inject information about
 computing resource requests and limits using environment variables.
 
+When creating the pod configuration, specify environment variables that
+correspond to the contents of the `resources` field in the `*spec.container*`
+field.
+
+[NOTE]
+====
+If the resource limits are not included in the container configuration, the
+downward API defaults to the node's CPU and memory allocatable values.
+====
+
 .Procedure
 
-To use environment variables:
+. Create a new pod spec that contains the resources you want to inject:
 
-. When creating a pod configuration, specify environment variables that
-correspond to the contents of the `resources` field in the `*spec.container*`
-field:
+.. Create a `pod.yaml` file similar to the following:
 +
 [source,yaml]
 ----
-....
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-env-test-pod
 spec:
   containers:
     - name: test-container
@@ -49,13 +60,10 @@ spec:
           valueFrom:
             resourceFieldRef:
               resource: limits.memory
-....
+# ...
 ----
-+
-If the resource limits are not included in the container configuration, the
-downward API defaults to the node's CPU and memory allocatable values.
 
-. Create the pod from the `*_pod.yaml_*` file:
+.. Create the pod from the `pod.yaml` file:
 +
 [source,terminal]
 ----