Merge pull request #37124 from kmccarron-rh/sro-updates

Author: Bob Furu

modules/psap-special-resource-operator-installing-using-cli.adoc

@@ -35,7 +35,7 @@ metadata:
 $ oc create -f sro-namespace.yaml
 ----
 
-. Install SRO in the namespace you created in the previous step:
+. Install the SRO in the namespace you created in the previous step:
 
 .. Create the following `OperatorGroup` CR and save the YAML in the `sro-operatorgroup.yaml` file:
 +
@@ -74,7 +74,7 @@ $ oc get packagemanifest special-resource-operator -n openshift-marketplace -o j
 
 .. Create the following `Subscription` CR and save the YAML in the `sro-sub.yaml` file:
 +
-.Example subscription CR
+.Example Subscription CR
 [source,yaml]
 ----
 apiVersion: operators.coreos.com/v1alpha1

modules/psap-special-resource-operator-installing-using-web-console.adoc

@@ -45,5 +45,5 @@ During installation, an Operator might display a *Failed* status. If the install
 +
 [NOTE]
 ====
-The Node Feature Discovery (NFD) Operator is a dependency of the Special Resource Operator (SRO). If the NFD Operator is not installed before installing SRO, the Operator Lifecycle Manager will automatically install the NFD Operator. However, the required Node Feature Discovery operand will not be deployed automatically. The Node Feature Discovery Operator documentation provides details about how to deploy NFD by using the NFD Operator.
+The Node Feature Discovery (NFD) Operator is a dependency of the Special Resource Operator (SRO). If the NFD Operator is not installed before installing the SRO, the Operator Lifecycle Manager will automatically install the NFD Operator. However, the required Node Feature Discovery operand will not be deployed automatically. The Node Feature Discovery Operator documentation provides details about how to deploy NFD by using the NFD Operator.
 ====

modules/psap-special-resource-operator-using-configmaps.adoc

@@ -5,15 +5,15 @@
 [id="deploy-simple-kmod-using-configmap-chart"]
 = Building and running the simple-kmod SpecialResource by using a config map
 
-In this example, the simple-kmod kernel module is used to show how SRO can manage a driver container which is defined in Helm chart templates stored in a config map.
+In this example, the simple-kmod kernel module is used to show how the SRO can manage a driver container which is defined in Helm chart templates stored in a config map.
 
 .Prerequisites
 
 * You have a running {product-title} cluster.
 * You set the Image Registry Operator state to `Managed` for your cluster.
 * You installed the OpenShift CLI (`oc`).
 * You are logged into the OpenShift CLI as a user with `cluster-admin` privileges.
-* You installed Node Feature Discovery (NFD) Operator.
+* You installed the Node Feature Discovery (NFD) Operator.
 * You installed the Special Resource Operator.
 * You installed the Helm CLI (`helm`).
 
@@ -31,7 +31,7 @@ $ mkdir -p chart/simple-kmod-0.0.1/templates
 $ cd chart/simple-kmod-0.0.1/templates
 ----
 
-.. Save this YAML template for the image stream and build config in the `templates` directory as `0000-buildconfig.yaml`.
+.. Save this YAML template for the image stream and build config in the `templates` directory as `0000-buildconfig.yaml`:
 +
 [source,yaml]
 ----
@@ -82,7 +82,7 @@ spec:
       kind: ImageStreamTag
       name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}}:v{{.Values.kernelFullVersion}} <1>
 ----
-<1> The templates such as `{{.Values.specialresource.metadata.name}}` are filled in by SRO, based on fields in the `SpecialResource` CR and variables known to the Operator such as `{{.Values.KernelFullVersion}}`
+<1> The templates such as `{{.Values.specialresource.metadata.name}}` are filled in by the SRO, based on fields in the `SpecialResource` CR and variables known to the Operator such as `{{.Values.KernelFullVersion}}`.
 
 .. Save the following YAML template for the RBAC resources and daemon set in the `templates` directory as `1000-driver-container.yaml`:
 +
@@ -198,7 +198,7 @@ $ helm package simple-kmod-0.0.1/
 Successfully packaged chart and saved it to: /data/<username>/git/<github_username>/special-resource-operator/yaml-for-docs/chart/simple-kmod-0.0.1/simple-kmod-0.0.1.tgz
 ----
 
-. Create a configuration map to store the chart files:
+. Create a config map to store the chart files:
 .. Create a directory for the config map files:
 +
 [source,terminal]
@@ -261,7 +261,7 @@ spec:
         uri: "https://github.com/openshift-psap/kvc-simple-kmod.git"
 ----
 <1> Optional: Uncomment the `#debug: true` line to have the YAML files in the chart printed in full in the Operator logs and to verify that the logs are created and templated properly.
-<2> The `spec.chart.repository.url` field tells SRO to look for the chart in a config map.
+<2> The `spec.chart.repository.url` field tells the SRO to look for the chart in a config map.
 
 . From a command line, create the `SpecialResource` file:
 +

modules/psap-special-resource-operator-using-manifests.adoc

@@ -5,7 +5,7 @@
 [id="deploy-simple-kmod-using-local-chart_{context}"]
 = Building and running the simple-kmod SpecialResource by using the templates from the SRO image
 
-The SRO image contains a local repository of Helm charts including the templates for deploying the simple-kmod kernel module. In this example, the simple-kmod kernel module is used to show how SRO can manage a driver container that is defined in the internal SRO repository.
+The SRO image contains a local repository of Helm charts including the templates for deploying the simple-kmod kernel module. In this example, the simple-kmod kernel module is used to show how the SRO can manage a driver container that is defined in the internal SRO repository.
 
 .Prerequisites
 
@@ -81,7 +81,7 @@ simple-kmod-driver-container-12813789169ac0ee-qtkff   1/1     Running     0
 $ oc logs pod/simple-kmod-driver-build-12813789169ac0ee-1-build -n simple-kmod
 ----
 
-. To verify that the simple-kmod kernel modules are loaded, execute the `lsmod` command in one of the driver container pods that was returned from the `oc get pods` command above. 
+. To verify that the simple-kmod kernel modules are loaded, execute the `lsmod` command in one of the driver container pods that was returned from the `oc get pods` command above: 
 +
 [source,terminal]
 ----

modules/psap-special-resource-operator-using.adoc

@@ -3,9 +3,9 @@
 // * hardware_enablement/psap-special-resource-operator.adoc
 
 [id="using-the-special-resource-operator_{context}"]
-= Using Special Resource Operator
+= Using the Special Resource Operator
 
-Special Resource Operator (SRO) is used to manage the build and deployment of a driver container. The objects required to build and deploy the container can be defined in a Helm chart. 
+The Special Resource Operator (SRO) is used to manage the build and deployment of a driver container. The objects required to build and deploy the container can be defined in a Helm chart. 
 
-The examples in this section use the simple-kmod kernel module to demonstrate how to use SRO to build and run a driver container.
+The examples in this section use the simple-kmod kernel module to demonstrate how to use the SRO to build and run a driver container.
 In the first example, the SRO image contains a local repository of Helm charts including the templates for deploying the simple-kmod kernel module. In this case, a `SpecialResource` manifest is used to deploy the driver container. In the second example, the simple-kmod `SpecialResource` object points to a `ConfigMap` object that is created to store the Helm charts.

modules/psap-special-resource-operator.adoc

@@ -3,8 +3,8 @@
 // * hardware_enablement/psap-special-resource-operator.adoc
 
 [id="about-special-resource-operator_{context}"]
-= About Special Resource Operator
+= About the Special Resource Operator
 
-Special Resource Operator (SRO) helps you manage the deployment of kernel modules and drivers on an existing {product-title} cluster. SRO can be used for a case as simple as building and loading a single kernel module, or as complex as deploying the driver, device plug-in, and monitoring stack for a hardware accelerator.
+The Special Resource Operator (SRO) helps you manage the deployment of kernel modules and drivers on an existing {product-title} cluster. The SRO can be used for a case as simple as building and loading a single kernel module, or as complex as deploying the driver, device plug-in, and monitoring stack for a hardware accelerator.
 
-For loading kernel modules, SRO is designed around the use of driver containers. Driver containers are increasingly being used in cloud-native environments, especially when run on pure container operating systems, to deliver hardware drivers to the host. Driver containers extend the kernel stack beyond the out-of-the-box software and hardware features of a specific kernel. Driver containers work on various container-capable Linux distributions. With driver containers, the host operating system stays clean and there is no clash between different library versions or binaries on the host.
+For loading kernel modules, the SRO is designed around the use of driver containers. Driver containers are increasingly being used in cloud-native environments, especially when run on pure container operating systems, to deliver hardware drivers to the host. Driver containers extend the kernel stack beyond the out-of-the-box software and hardware features of a specific kernel. Driver containers work on various container-capable Linux distributions. With driver containers, the host operating system stays clean and there is no clash between different library versions or binaries on the host.