OSDOCS 16932 CQA 2.0 of NODES-4: Container/Pod Runtime Configuration

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

@@ -6,21 +6,22 @@
 [id="nodes-containers-copying-files-about_{context}"]
 = Understanding how to copy files
 
-The `oc rsync` command, or remote sync, is a useful tool for copying database archives to and from your pods for backup and restore purposes.
+[role="_abstract"]
+You can use the `oc rsync` command, or remote sync, for copying database archives to and from your pods for backup and restore purposes.
 You can also use `oc rsync` to copy source code changes into a running pod for development debugging, when the running pod supports hot reload of source files.
 
 [source,terminal]
 ----
 $ oc rsync <source> <destination> [-c <container>]
 ----
 
-== Requirements
+When using the `oc rysnc` command, note the following requirements. 
 
 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
+When specifying a pod directory, the directory name must be prefixed with the pod
 name:
 +
 [source,terminal]
@@ -37,13 +38,13 @@ the directory does not exist, but `rsync` is used for copy, the directory is
 created for you.
 
 Deleting Files at the Destination::
-The `--delete` flag may be used to delete any files in the remote directory that
+The `--delete` flag can be used to delete any files in the remote directory that
 are not in the local directory.
 
 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.
+argument, the command runs continuously.
 +
 Synchronization occurs after short quiet periods to ensure a
 rapidly changing file system does not result in continuous synchronization

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

@@ -6,12 +6,11 @@
 [id="nodes-containers-copying-files-procedure_{context}"]
 = Copying files to and from containers
 
-Support for copying local files to or from a container is built into the CLI.
+[role="_abstract"]
+You can use the `oc rsync` command for copying local files to or from a container.
 
 .Prerequisites
 
-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
 machine and the remote container.
 +

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

@@ -6,11 +6,14 @@
 [id="nodes-containers-copying-files-rsync_{context}"]
 = Using advanced Rsync features
 
-The `oc rsync` command exposes fewer command-line options than standard `rsync`.
+[role="_abstract"]
+You can use the additional command-line options that are available with the standard `rsync` command if needed. 
+
+The `oc rsync` command exposes fewer command-line options than standard `rsync` command.
 In the case that you want to use a standard `rsync` command-line option that is
-not available in `oc rsync`, for example the `--exclude-from=FILE` option, it
-might be possible to use standard `rsync` 's `--rsh` (`-e`) option or `RSYNC_RSH`
-environment variable as a workaround, as follows:
+not available with the `oc rsync` command, for example the `--exclude-from=FILE` option, it
+might be possible to use standard `rsync` with the `--rsh` (`-e`) option or `RSYNC_RSH`
+environment variable as a workaround, as shown in the following examples:
 
 [source,terminal]
 ----
@@ -33,6 +36,6 @@ Then, run the rsync command:
 $ 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
+Both of the above examples configure the standard `rsync` command to use `oc rsh` as its
 remote shell program to enable it to connect to the remote pod, and are an
 alternative to running `oc rsync`.

modules/nodes-containers-dev-fuse-configuring.adoc

@@ -6,7 +6,10 @@
 [id="nodes-containers-dev-fuse-configuring_{context}"]
 = Configuring /dev/fuse for unprivileged builds in pods
 
-By exposing the `/dev/fuse` device to an unprivileged pod, you grant it the capability to perform Filesystem in Userspace (FUSE) mounts. This is achieved by adding the `io.kubernetes.cri-o.Devices: "/dev/fuse"` annotation to your pod definition. This setup allows an unprivileged user within the pod to use tools like `podman` with storage drivers such as `fuse-overlayfs` by mimicking privileged build capabilities in a secure and efficient manner without granting full privileged access to the pod.
+[role="_abstract"]
+You can grant an unprivileged pod the capability to perform Filesystem in Userspace (FUSE) mounts by exposing the `/dev/fuse` device. With this setup, an unprivileged user within the pod can use tools such as `podman` with storage drivers such as `fuse-overlayfs` by mimicking privileged build capabilities in a secure and efficient manner without granting full privileged access to the pod.
+
+You expose the `/dev/fuse` device by adding the `io.kubernetes.cri-o.Devices: "/dev/fuse"` annotation to your pod definition.
 
 .Procedure
 
@@ -34,10 +37,10 @@ spec:
 +
 where:
 +
-`io.kubernetes.cri-o.Devices`:: The `io.kubernetes.cri-o.Devices: "/dev/fuse"` annotation makes the FUSE device available.
-`image`:: This annotation specifies a container that uses an image that includes `podman` (for example, `quay.io/podman/stable`).
-`args`:: This command keeps the container running so you can `exec` into it.
-`securityContext`:: This annotation specifies a `securityContext` that runs the container as an unprivileged user (for example, `runAsUser: 1000`).
+`metadata.annotations`:: Specifies that the `io.kubernetes.cri-o.Devices: "/dev/fuse"` annotation makes the FUSE device available.
+`spec.containers.image`:: Specifies a container that uses an image that includes `podman` (for example, `quay.io/podman/stable`).
+`spec.containers.args`:: Specifies a command to keep the container running so you can `exec` into it.
+`spec.containers.securityContext`:: Specifies a `securityContext` that runs the container as an unprivileged user (for example, `runAsUser: 1000`).
 +
 [NOTE]
 ====
@@ -51,23 +54,25 @@ Depending on your cluster's Security Context Constraints (SCCs) or other policie
 $ oc apply -f fuse-builder-pod.yaml
 ----
 
-. Verify that the pod is running:
+. Verify that the pod is running by running the following command:
 +
 [source,terminal]
 ----
 $ oc get pods fuse-builder-pod
 ----
 
 . Access the pod and prepare the build environment:
-+
-After the `fuse-builder-pod` pod is in the `Running` state, open a shell session into the `build-container` environment:
+
+.. After the `fuse-builder-pod` pod is in the `Running` state, open a shell session into the `build-container` environment by running the following command:
 +
 [source,terminal]
 ----
 $ oc exec -ti fuse-builder-pod -- /bin/bash
 ----
 +
-You are now inside the container. Because the default working directory might not be writable by the unprivileged user, change to a writable directory like `/tmp`:
+You are now inside the container. 
+
+.. Because the default working directory might not be writable by an unprivileged user, change to a writable directory such as `/tmp` by running the following commands:
 +
 [source,terminal]
 ----
@@ -84,7 +89,7 @@ $ pwd
 /tmp
 ----
 
-. Create a dockerfile and build an image using Podman:
+. Create a dockerfile and build an image by using Podman:
 +
 Inside the pod's shell and within the `/tmp` directory, you can now create a `Dockerfile` and use `podman` to build a container image. If `fuse-overlayfs` is the default or configured storage driver, Podman is able to leverage `fuse-overlayfs` because of the available `/dev/fuse` device.
 +
@@ -102,7 +107,7 @@ CMD ["sh", "-c", "cat /app/build_info.txt && echo '--- Copied Dockerfile ---' &&
 EOF
 ----
 +
-.. Build the image using `podman`. The `-t` flag tags the image:
+.. Build the image by running the following command. The `-t` flag tags the image.
 +
 [source,terminal]
 ----
@@ -113,7 +118,7 @@ You should see Podman executing the build steps.
 
 . Optional: Test the built image:
 +
-Still inside the `fuse-builder-pod`, you can run a container from the image you just built to test it:
+Still inside the `fuse-builder-pod`, you can run a container from the image you just built to test it by running the following command:
 +
 [source,terminal]
 ----
@@ -124,21 +129,21 @@ This should output the content of the `/app/build_info.txt` file and the copied
 
 . Exit the pod and clean up:
 +
-.. After you are done, exit the shell session in the pod:
+.. After you are done, exit the shell session in the pod by running the following command:
 +
 [source,terminal]
 ----
 $ exit
 ----
 +
-.. Delete the pod if it's no longer needed:
+.. Delete the pod if it is no longer needed by running the following command:
 +
 [source,terminal]
 ----
 $ oc delete pod fuse-builder-pod
 ----
 +
-.. Remove the local YAML file:
+.. Remove the local YAML file by running the following command:
 +
 [source,terminal]
 ----

modules/nodes-containers-downward-api-about.adoc

@@ -6,9 +6,9 @@
 [id="nodes-containers-projected-volumes-about_{context}"]
 = Expose pod information to Containers using the Downward API
 
-The Downward API contains such information as the pod's name, project, and resource values. Containers can consume
-information from the downward API using environment variables or a volume
-plugin.
+[role="_abstract"]
+You can review the following tables to learn what information the Downward API contains, including the pod's name, project, and resource values. Your containers can consume this
+information by using environment variables or a volume plugin.
 
 Fields within the pod are selected using the `FieldRef` API type. `FieldRef`
 has two fields:

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

@@ -6,8 +6,9 @@
 [id="nodes-containers-downward-api-container-configmaps_{context}"]
 = Consuming configuration maps using the Downward API
 
+[role="_abstract"]
 When creating pods, you can use the Downward API to inject configuration map values
-so image and application authors can create an image for specific environments.
+so that image and application authors can create an image for specific environments.
 
 .Procedure
 
@@ -25,7 +26,7 @@ data:
   mykey: myvalue
 ----
 
-.. Create the config map from the `configmap.yaml` file:
+.. Create the config map from the `configmap.yaml` file by using the following command:
 +
 [source,terminal]
 ----
@@ -65,7 +66,7 @@ spec:
 # ...
 ----
 
-.. Create the pod from the `pod.yaml` file:
+.. Create the pod from the `pod.yaml` file by using the following command:
 +
 [source,terminal]
 ----
@@ -74,7 +75,7 @@ $ oc create -f pod.yaml
 
 .Verification
 
-* Check the container's logs for the `MY_CONFIGMAP_VALUE` value:
+* Check the container's logs for the `MY_CONFIGMAP_VALUE` value by using the following command:
 +
 [source,terminal]
 ----

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

@@ -6,9 +6,11 @@
 [id="nodes-containers-downward-api-container-envars_{context}"]
 = Referencing environment variables
 
-When creating pods, you can reference the value of a previously defined
-environment variable by using the `$()` syntax. If the environment variable
-reference can not be resolved, the value will be left as the provided
+[role="_abstract"]
+When creating pods, you can reference the value of a previously defined environment variable by using the `$()` syntax. By using this syntax, you can reference variables that you define within a pod configuration elsewhere in that configuration.
+
+If the environment variable
+reference cannot be resolved, the value will be left as the provided
 string.
 
 .Procedure
@@ -45,7 +47,7 @@ spec:
 # ...
 ----
 
-.. Create the pod from the `*_pod.yaml_*` file:
+.. Create the pod from the `*_pod.yaml_*` file by using the following command:
 +
 [source,terminal]
 ----
@@ -54,7 +56,7 @@ $ oc create -f pod.yaml
 
 .Verification
 
-* Check the container's logs for the `MY_ENV_VAR_REF_ENV` value:
+* Check the container's logs for the `MY_ENV_VAR_REF_ENV` value by using the following command:
 +
 [source,terminal]
 ----

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

@@ -6,6 +6,7 @@
 [id="nodes-containers-downward-api-container-escaping_{context}"]
 = Escaping environment variable references
 
+[role="_abstract"]
 When creating a pod, you can escape an environment variable reference by using
 a double dollar sign. The value will then be set to a single dollar sign version
 of the provided value.
@@ -42,7 +43,7 @@ spec:
 # ...
 ----
 
-.. Create the pod from the `*_pod.yaml_*` file:
+.. Create the pod from the `*_pod.yaml_*` file by using the following command:
 +
 [source,terminal]
 ----
@@ -51,7 +52,7 @@ $ oc create -f pod.yaml
 
 .Verification
 
-* Check the container's logs for the `MY_NEW_ENV` value:
+* Check the container's logs for the `MY_NEW_ENV` value by using the following command:
 +
 [source,terminal]
 ----

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

@@ -6,10 +6,9 @@
 [id="nodes-containers-downward-api-container-resources-envars_{context}"]
 = Consuming container resources using environment variables
 
+[role="_abstract"]
 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
+computing resource requests and limits by using environment variables that
 correspond to the contents of the `resources` field in the `*spec.container*`
 field.
 
@@ -63,7 +62,7 @@ spec:
 # ...
 ----
 
-.. Create the pod from the `pod.yaml` file:
+.. Create the pod from the `pod.yaml` file by using the following command:
 +
 [source,terminal]
 ----

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

@@ -6,11 +6,9 @@
 [id="nodes-containers-downward-api-container-resources-plugin_{context}"]
 = Consuming container resources using a volume plugin
 
+[role="_abstract"]
 When creating pods, you can use the Downward API to inject information about
-computing resource requests and limits using a volume plugin.
-
-When creating the pod configuration, use the `spec.volumes.downwardAPI.items`
-field to describe the desired resources that correspond to the
+computing resource requests and limits by using a volume plugin to describe the desired resources that correspond to the
 `spec.resources` field.
 
 [NOTE]
@@ -70,7 +68,7 @@ spec:
 # ...
 ----
 
-.. Create the pod from the `*_volume-pod.yaml_*` file:
+.. Create the pod from the `*_volume-pod.yaml_*` file by using the following command:
 +
 [source,terminal]
 ----

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

@@ -6,9 +6,9 @@
 [id="nodes-containers-downward-api-container-resources-api_{context}"]
 = Understanding how to consume container resources using the Downward API
 
+[role="_abstract"]
 When creating pods, you can use the Downward API to inject information about
 computing resource requests and limits so that image and application authors can
 correctly create an image for specific environments.
 
 You can do this using environment variable or a volume plugin.
-

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

@@ -6,6 +6,7 @@
 [id="nodes-containers-downward-api-container-secrets_{context}"]
 = Consuming secrets using the Downward API
 
+[role="_abstract"]
 When creating pods, you can use the downward API to inject secrets
 so image and application authors can create an image
 for specific environments.
@@ -28,7 +29,7 @@ data:
 type: kubernetes.io/basic-auth
 ----
 
-.. Create the secret object from the `secret.yaml` file:
+.. Create the secret object from the `secret.yaml` file by using the following command:
 +
 [source,terminal]
 ----
@@ -68,7 +69,7 @@ spec:
 # ...
 ----
 
-.. Create the pod from the `pod.yaml` file:
+.. Create the pod from the `pod.yaml` file by using the following command:
 +
 [source,terminal]
 ----
@@ -77,7 +78,7 @@ $ oc create -f pod.yaml
 
 .Verification
 
-* Check the container's logs for the `MY_SECRET_USERNAME` value:
+* Check the container logs for the `MY_SECRET_USERNAME` value by using the following command:
 +
 [source,terminal]
 ----