Merge pull request #59925 from bergerhoffer/413_typo_check

bergerhoffer · web-flow · commit 125af3d46e1f · 2023-05-15T08:40:20.000-04:00
Typo fixes
diff --git a/installing/install_config/enabling-cgroup-v2.adoc b/installing/install_config/enabling-cgroup-v2.adoc
@@ -10,9 +10,9 @@ toc::[]
 ifndef::openshift-origin[]
 By default, {product-title} uses link:https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1.html[Linux control group version 1] (cgroup v1) in your cluster. You can enable link:https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html[Linux control group version 2] (cgroup v2) upon installation. Enabling cgroup v2 in {product-title} disables all cgroup version 1 controllers and hierarchies in your cluster.
 
-cgroup v2 is the next version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as link:https://www.kernel.org/doc/html/latest/accounting/psi.html[Pressure Stall Information], and enhanced resource management and isolation. 
+cgroup v2 is the next version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as link:https://www.kernel.org/doc/html/latest/accounting/psi.html[Pressure Stall Information], and enhanced resource management and isolation.
 
-You can switch between cgroup v1 and cgroup v2, as needed, by editing the the `node.config` object. For more information, see "Configuring the Linux cgroup on your nodes" in the "Additional resources" of this section.
+You can switch between cgroup v1 and cgroup v2, as needed, by editing the `node.config` object. For more information, see "Configuring the Linux cgroup on your nodes" in the "Additional resources" of this section.
 endif::openshift-origin[]
 
 ifdef::openshift-origin[]
diff --git a/modules/cnf-configuring-node-groups-for-the-numaresourcesoperator.adoc b/modules/cnf-configuring-node-groups-for-the-numaresourcesoperator.adoc
@@ -7,11 +7,11 @@
 [id="cnf-configuring-node-groups-for-the-numaresourcesoperator_{context}"]
 = Optional: Configuring polling operations for NUMA resources updates
 
-The daemons controlled by the NUMA Resources Operator in their `nodeGroup` poll resources to retrieve updates about available NUMA resources. You can fine-tune polling operations for these daemons by configuring the `spec.nodeGroups` specification in the `NUMAResourcesOperator` custom resource (CR). This provides advanced control of polling operations. Configure these specifications to improve scheduling behaviour and troubleshoot suboptimal scheduling decisions. 
+The daemons controlled by the NUMA Resources Operator in their `nodeGroup` poll resources to retrieve updates about available NUMA resources. You can fine-tune polling operations for these daemons by configuring the `spec.nodeGroups` specification in the `NUMAResourcesOperator` custom resource (CR). This provides advanced control of polling operations. Configure these specifications to improve scheduling behaviour and troubleshoot suboptimal scheduling decisions.
 
 The configuration options are the following:
 
-* `infoRefreshMode`: Determines the trigger condition for polling the kublet. The NUMA Resources Operator reports the resulting information to the API server. 
+* `infoRefreshMode`: Determines the trigger condition for polling the kubelet. The NUMA Resources Operator reports the resulting information to the API server.
 * `infoRefreshPeriod`: Determines the duration between polling updates.
 * `podsFingerprinting`: Determines if point-in-time information for the current set of pods running on a node is exposed in polling updates.
 +
@@ -44,7 +44,7 @@ spec:
       podsFingerprinting: Enabled <3>
     name: worker
 ----
-<1> Valid values are `Periodic`, `Events`, `PeriodicAndEvents`. Use `Periodic` to poll the kublet at intervals that you define in `infoRefreshPeriod`. Use `Events` to poll the kublet at every pod lifecycle event. Use `PeriodicAndEvents` to enable both methods.
+<1> Valid values are `Periodic`, `Events`, `PeriodicAndEvents`. Use `Periodic` to poll the kubelet at intervals that you define in `infoRefreshPeriod`. Use `Events` to poll the kubelet at every pod lifecycle event. Use `PeriodicAndEvents` to enable both methods.
 <2> Define the polling interval for `Periodic` or `PeriodicAndEvents` refresh modes. The field is ignored if the refresh mode is `Events`.
 <3> Valid values are `Enabled` or `Disabled`. Setting to `Enabled` is a requirement for the `cacheResyncPeriod` specification in the `NUMAResourcesScheduler`.
 
@@ -70,4 +70,4 @@ $ oc get numaresop numaresourcesoperator -o json | jq '.status'
       "name": "worker"
 
       ...
-----
+----
diff --git a/modules/cnf-scheduling-numa-aware-workloads-overview-with-manual-performance-settings.adoc b/modules/cnf-scheduling-numa-aware-workloads-overview-with-manual-performance-settings.adoc
@@ -5,4 +5,4 @@
 [id="cnf-scheduling-numa-aware-workloads-with-manual-perofrmance-settings_{context}"]
 = Scheduling NUMA-aware workloads with manual performance settings
 
-Clusters running latency-sensitive workloads typically feature performance profiles that help to minimize workload latency and optimize performance. However, you can schedule NUMA-aware workloads in a pristine cluster that does not feature a performance profile. The following workflow features a pristine cluster that you can manually configure for performance by using the `KubletConfig` resource. This is not the typical environment for scheduling NUMA-aware workloads.  
+Clusters running latency-sensitive workloads typically feature performance profiles that help to minimize workload latency and optimize performance. However, you can schedule NUMA-aware workloads in a pristine cluster that does not feature a performance profile. The following workflow features a pristine cluster that you can manually configure for performance by using the `KubeletConfig` resource. This is not the typical environment for scheduling NUMA-aware workloads.  
diff --git a/modules/deployment-plug-in-cluster.adoc b/modules/deployment-plug-in-cluster.adoc
@@ -91,5 +91,5 @@ You can see the list of the enabled plugins on the *Overview* page or by navigat
 
 [NOTE]
 ====
-It can take a few minutes for the new plugin configuration to appear. If you do not see your plugin, you might need to refresh your browser if the plugin was recently enabled. If you recieve any errors at runtime, check the JS console in browser developer tools to look for any errors in your plugin code.
+It can take a few minutes for the new plugin configuration to appear. If you do not see your plugin, you might need to refresh your browser if the plugin was recently enabled. If you receive any errors at runtime, check the JS console in browser developer tools to look for any errors in your plugin code.
 ====
diff --git a/modules/ipi-install-configuring-host-dual-network-interfaces-in-the-install-config.yaml-file.adoc b/modules/ipi-install-configuring-host-dual-network-interfaces-in-the-install-config.yaml-file.adoc
@@ -112,7 +112,7 @@ hosts:
                 next-hop-interface: bond0 <14>
                 table-id: 254
 ----
-<1> The `networkConfig`` field contains information about the network configuration of the host, with subfields including `interfaces``,`dns-resolver`, and `routes`.
+<1> The `networkConfig` field contains information about the network configuration of the host, with subfields including `interfaces`, `dns-resolver`, and `routes`.
 <2> The `interfaces` field is an array of network interfaces defined for the host.
 <3> The name of the interface.
 <4> The type of interface. This example creates a ethernet interface.
diff --git a/modules/lvms-scaling-storage-of-single-node-openshift-cluster-using-rhacm.adoc b/modules/lvms-scaling-storage-of-single-node-openshift-cluster-using-rhacm.adoc
@@ -6,7 +6,7 @@
 [id="lvms-scaling-storage-of-single-node-openshift-cluster-using-rhacm_{context}"]
 = Scaling up storage by adding capacity to your {sno} cluster using {rh-rhacm}
 
-You can scale the the storage capacity of your configured worker nodes on a {sno} cluster using {rh-rhacm}.
+You can scale the storage capacity of your configured worker nodes on a {sno} cluster using {rh-rhacm}.
 
 .Prerequisites
 
diff --git a/modules/machine-lifecycle-hook-deletion-format.adoc b/modules/machine-lifecycle-hook-deletion-format.adoc
@@ -40,7 +40,7 @@ spec:
   ...
 ----
 <1> The name of the `preTerminate` lifecycle hook.
-<2> The hook-implementing controller that that manages the `preTerminate` lifecycle hook.
+<2> The hook-implementing controller that manages the `preTerminate` lifecycle hook.
 
 [discrete]
 [id="machine-lifecycle-hook-deletion-example_{context}"]
diff --git a/modules/machineset-upi-reqs-ignition-config.adoc b/modules/machineset-upi-reqs-ignition-config.adoc
@@ -14,7 +14,7 @@ endif::[]
 
 Provisioning virtual machines (VMs) requires a valid Ignition configuration. The Ignition configuration contains the `machine-config-server` address and a system trust bundle for obtaining further Ignition configurations from the Machine Config Operator.
 
-By default, this configuration is stored in the `worker-user-data` secret in the the `machine-api-operator` namespace. Compute machine sets reference the secret during the machine creation process.
+By default, this configuration is stored in the `worker-user-data` secret in the `machine-api-operator` namespace. Compute machine sets reference the secret during the machine creation process.
 
 .Procedure
 
diff --git a/modules/microshift-accessing-cluster-open-firewall.adoc b/modules/microshift-accessing-cluster-open-firewall.adoc
@@ -14,7 +14,7 @@ Use the following procedure to open the firewall so that a remote user can acces
 
 .Prerequisites
 
-* You have installed the the `oc` binary.
+* You have installed the `oc` binary.
 
 .Procedure
 
@@ -32,4 +32,4 @@ Use the following procedure to open the firewall so that a remote user can acces
 [source,terminal]
 ----
 [user@microshift]$ oc get all -A
-----
+----
diff --git a/modules/microshift-accessing-cluster-remotely.adoc b/modules/microshift-accessing-cluster-remotely.adoc
@@ -14,7 +14,7 @@ Use the following procedure to access the {product-title} cluster from a remote
 
 .Prerequisites
 
-* You have installed the the `oc` binary.
+* You have installed the `oc` binary.
 
 * The `@user@microshift` has opened the firewall from the local host.
 
diff --git a/modules/nodes-nodes-configuring-graceful-shutdown.adoc b/modules/nodes-nodes-configuring-graceful-shutdown.adoc
@@ -36,9 +36,9 @@ spec:
     shutdownGracePeriod: "3m" <2>
     shutdownGracePeriodCriticalPods: "2m" <3>
 ----
-<1> This example applies shutdown grace periods to nodes with the `worker` role. 
+<1> This example applies shutdown grace periods to nodes with the `worker` role.
 <2> Define a time period for regular pods to shut down.
-<3> Define a time period for critical pods to shut down. 
+<3> Define a time period for critical pods to shut down.
 
 . Create the `KubeletConfig` CR by running the following command:
 +
@@ -55,11 +55,11 @@ kubeletconfig.machineconfiguration.openshift.io/graceful-shutdown created
 
 .Verification
 
-. View the kubelet logs for a node to verify the grace period configuration by using the command line or by viewing the `kublet.conf` file.
+. View the kubelet logs for a node to verify the grace period configuration by using the command line or by viewing the `kubelet.conf` file.
 +
 [NOTE]
 ====
-Ensure that the log messages for `shutdownGracePeriodRequested` and `shutdownGracePeriodCriticalPods` match the values set in the `KubeletConfig` CR. 
+Ensure that the log messages for `shutdownGracePeriodRequested` and `shutdownGracePeriodCriticalPods` match the values set in the `KubeletConfig` CR.
 ====
 
 .. To view the logs by using the command line, run the following command, replacing `<node_name>` with the name of the node:
@@ -87,9 +87,9 @@ ShutdownGracePeriodSeconds:600}]
 ...
 ----
 +
-<1> Ensure that the log messages for `shutdownGracePeriodRequested` and `shutdownGracePeriodCriticalPods` match the values set in the `KubeletConfig` CR. 
+<1> Ensure that the log messages for `shutdownGracePeriodRequested` and `shutdownGracePeriodCriticalPods` match the values set in the `KubeletConfig` CR.
 +
-.. To view the logs in the `kublet.conf` file on a node, run the following commands to enter a debug session on the node:
+.. To view the logs in the `kubelet.conf` file on a node, run the following commands to enter a debug session on the node:
 +
 [source,terminal]
 ----
@@ -103,7 +103,7 @@ $ chroot /host
 +
 [source,terminal]
 ----
-$ cat /etc/kubernetes/kubelet.conf 
+$ cat /etc/kubernetes/kubelet.conf
 ----
 +
 .Example output
diff --git a/modules/nw-ingress-sharding-dns.adoc b/modules/nw-ingress-sharding-dns.adoc
@@ -1,4 +1,4 @@
-// Module included in the folllowing assemblies:
+// Module included in the following assemblies:
 //
 // * networking/ingress-sharding.adoc
 
diff --git a/modules/nw-ovn-kubernetes-features.adoc b/modules/nw-ovn-kubernetes-features.adoc
@@ -5,7 +5,7 @@
 [id="nw-ovn-kubernetes-purpose_{context}"]
 = OVN-Kubernetes purpose
 
-The OVN-Kubnernetes network plugin is an open-source, fully-featured Kubernetes CNI plugin that uses Open Virtual Network (OVN) to manage network traffic flows. OVN is a community developed, vendor-agnostic network virtualization solution. The OVN-Kubnernetes network plugin:
+The OVN-Kubernetes network plugin is an open-source, fully-featured Kubernetes CNI plugin that uses Open Virtual Network (OVN) to manage network traffic flows. OVN is a community developed, vendor-agnostic network virtualization solution. The OVN-Kubernetes network plugin:
 
 // OVN (Open Virtual Network) is consistent with upstream usage.
 
diff --git a/modules/nw-ovn-kubernetes-install-ovnkube-trace-local.adoc b/modules/nw-ovn-kubernetes-install-ovnkube-trace-local.adoc
@@ -6,7 +6,7 @@
 [id="nw-ovn-kubernetes-install-ovnkube-trace-local_{context}"]
 = Installing the ovnkube-trace on local host
 
-The `ovnkube-trace` tool traces packet simulations for arbitrary UDP or TCP traffic between points in a OVN-Kubernetes driven {product-title} cluster. Copy the `ovnkube-trace` binary to your local host making it available to run against the cluster.
+The `ovnkube-trace` tool traces packet simulations for arbitrary UDP or TCP traffic between points in an OVN-Kubernetes driven {product-title} cluster. Copy the `ovnkube-trace` binary to your local host making it available to run against the cluster.
 
 .Prerequisites
 
@@ -83,4 +83,4 @@ The log levels are:
 
 *  0 (minimal output)
 *  2 (more verbose output showing results of trace commands)
-*  5 (debug output)
+*  5 (debug output)
diff --git a/modules/nw-ovn-kubernetes-list-southbound-database-contents.adoc b/modules/nw-ovn-kubernetes-list-southbound-database-contents.adoc
@@ -138,7 +138,7 @@ This detailed output shows the chassis and the ports that are attached to the ch
 Any pods communicate out to the wider network using source network address translation (SNAT).
 Their IP address is translated into the IP address of the node that the pod is running on and then sent out into the network.
 +
-In addition to the the chassis information the southbound database has all the logic flows and those logic flows are then sent to the `ovn-controller` running on each of the nodes.
+In addition to the chassis information the southbound database has all the logic flows and those logic flows are then sent to the `ovn-controller` running on each of the nodes.
 The `ovn-controller` translates the logic flows into open flow rules and ultimately programs `OpenvSwitch` so that your pods can then follow open flow rules and make it out of the network.
 +
 Run the following command to display the options available with the command `ovn-sbctl`:
@@ -147,4 +147,4 @@ Run the following command to display the options available with the command `ovn
 ----
 $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
 -c northd -- ovn-sbctl --help
-----
+----
diff --git a/modules/op-filtering-pull-requests-using-GitHub-interceptor.adoc b/modules/op-filtering-pull-requests-using-GitHub-interceptor.adoc
@@ -9,11 +9,11 @@
 You can filter GitHub events based on the files that have been changed for push and pull events. This helps you to execute a pipeline for only relevant changes in your Git repository.
 GitHub Interceptor adds a comma delimited list of all files that have been changed and uses the CEL Interceptor to filter incoming events based on the changed files. The list of changed files is added to the `changed_files` property of the event payload in the top-level  `extensions` field. 
 
-.Prerequistes
+.Prerequisites
 * You have installed the {pipelines-title} Operator.
 
 .Procedure
-. Perform one of the following steps: 
+. Perform one of the following steps:
 * For a public GitHub repository, set the value of the `addChangedFiles` parameter to `true` in the YAML configuration file shown below:
 +
 [source,yaml]
diff --git a/modules/persistent-storage-efs-csi-driver-operator-setup.adoc b/modules/persistent-storage-efs-csi-driver-operator-setup.adoc
@@ -7,10 +7,10 @@
 [id="persistent-storage-efs-csi-driver-operator-setup_{context}"]
 = Setting up the {FeatureName} CSI Driver Operator
 
-. Install the the {FeatureName} CSI Driver Operator.
+. Install the {FeatureName} CSI Driver Operator.
 
 ifdef::openshift-rosa[]
 . If you are using {FeatureName} with AWS Secure Token Service (STS), configure the {FeatureName} CSI Driver with STS.
 endif::openshift-rosa[]
 
-. Install the {FeatureName} CSI Driver.
+. Install the {FeatureName} CSI Driver.
diff --git a/modules/virt-importing-vm-datavolume.adoc b/modules/virt-importing-vm-datavolume.adoc
@@ -74,7 +74,7 @@ spec:
             storage: 10Gi
         storageClassName: local
       source: <4>
-        http: 
+        http:
           url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" <4>
           secretRef: endpoint-secret <5>
           certConfigMap: "" <6>
@@ -112,7 +112,7 @@ status: {}
 <1> Specify the name of the virtual machine.
 <2> Specify the name of the data volume.
 <3> The volume and access mode are detected automatically for known storage provisioners. Alternatively, you can specify `Block`.
-<4> Specify either the URL or the registry endpoint of the virtual machine image you want to import using the comment block. For example, if you want to use a registry source, you can comment out or delete the the HTTP or HTTPS source block. Ensure that you replace the example values shown here with your own values.
+<4> Specify either the URL or the registry endpoint of the virtual machine image you want to import using the comment block. For example, if you want to use a registry source, you can comment out or delete the HTTP or HTTPS source block. Ensure that you replace the example values shown here with your own values.
 <5> Specify the `Secret` name if you created a `Secret` for the data source.
 <6> Optional: Specify a CA certificate config map.
 ====
diff --git a/networking/network_observability/network-observability-operator-release-notes.adoc b/networking/network_observability/network-observability-operator-release-notes.adoc
diff --git a/storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc b/storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc
diff --git a/updating/updating-hardware-on-nodes-running-on-vsphere.adoc b/updating/updating-hardware-on-nodes-running-on-vsphere.adoc
