Fixing some typos

Author: bergerhoffer

modules/cluster-logging-feature-reference.adoc

@@ -162,7 +162,7 @@ $ oc -n openshift-logging edit ClusterLogging instance
 | ARM support           | ✓ | ✓
 | PowerPC support       | ✓ | ✓
 | IBM Z support         | ✓ | ✓
-| IPV6 support          | ✓ | ✓
+| IPv6 support          | ✓ | ✓
 | Log event buffering   | ✓ |
 | Disconnected Cluster  | ✓ | ✓
 |===========================================================

modules/cnf-running-the-performance-creator-profile.adoc

@@ -110,7 +110,7 @@ The `info` option requires a value which specifies the output format. Possible v
 +
 [source,terminal,subs="attributes+"]
 ----
-$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:vBranch Build --mcp-name=worker-cnf --reserved-cpu-count=4 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=6 > my-performance-profile.yaml
+$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v{product-version} --mcp-name=worker-cnf --reserved-cpu-count=4 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=6 > my-performance-profile.yaml
 ----
 +
 [NOTE]

modules/installation-configuration-parameters.adoc

@@ -612,7 +612,7 @@ accounts for the dramatically decreased machine performance.
 |The only supported value is `3`, which is the default value.
 
 |`credentialsMode`
-|The Cloud Credential Operator (CCO) mode. If no mode is specified, the CCO dynamically tries to determine the capabilities of the provided credentials, with a preference for mint mode on the platforms where multiple modes are supported. 
+|The Cloud Credential Operator (CCO) mode. If no mode is specified, the CCO dynamically tries to determine the capabilities of the provided credentials, with a preference for mint mode on the platforms where multiple modes are supported.
 ifdef::gcp[If you are installing on GCP into a shared virtual private cloud (VPC), `credentialsMode` must be set to `Passthrough`.]
 [NOTE]
 ====
@@ -1175,7 +1175,7 @@ link:https://yaml.org/spec/1.2/spec.html#sequence//[YAML sequence].
 
 |`platform.gcp.defaultMachinePlatform.tags`
 |Optional. Additional network tags to add to the control plane and compute machines.
-|One or more strings, for example `network-tag1``.
+|One or more strings, for example `network-tag1`.
 
 |`platform.gcp.defaultMachinePlatform.type`
 |The link:https://cloud.google.com/compute/docs/machine-types[GCP machine type] for control plane and compute machines.
@@ -1383,7 +1383,7 @@ Additional {rh-virtualization} configuration parameters are described in the fol
 |String. For example: `3fa86930-0be5-4052-b667-b79f0a729692`
 
 |`platform.ovirt.api_vips`
-|Required. An IP address on the machine network that will be assigned to the API virtual IP (VIP). You can access the OpenShift API at this endpoint. For dual-stack networks, assign up to two IP addresses. The primary IP address must be from the IPv4 network. 
+|Required. An IP address on the machine network that will be assigned to the API virtual IP (VIP). You can access the OpenShift API at this endpoint. For dual-stack networks, assign up to two IP addresses. The primary IP address must be from the IPv4 network.
 
 [NOTE]
 ====
@@ -1393,7 +1393,7 @@ In {product-title} 4.12 and later, the `api_vip` configuration setting is deprec
 |String. Example: `10.46.8.230`
 
 |`platform.ovirt.ingress_vips`
-|Required. An IP address on the machine network that will be assigned to the Ingress virtual IP (VIP). For dual-stack networks, assign up to two IP addresses. The primary IP address must be from the IPv4 network. 
+|Required. An IP address on the machine network that will be assigned to the Ingress virtual IP (VIP). For dual-stack networks, assign up to two IP addresses. The primary IP address must be from the IPv4 network.
 
 [NOTE]
 ====

modules/nvidia-gpu-admin-dashboard-using.adoc

@@ -6,7 +6,7 @@
 [id="nvidia-gpu-admin-dashboard-using_{context}"]
 = Using the NVIDIA GPU administration dashboard
 
-After deploying the the OpenShift Console NVIDIA GPU plug-in, log in to the OpenShift Container Platform web console using your login credentials to access the *Administrator* perspective.
+After deploying the OpenShift Console NVIDIA GPU plug-in, log in to the OpenShift Container Platform web console using your login credentials to access the *Administrator* perspective.
 
 To view the changes, you need to refresh the console to see the **GPUs** tab under **Compute**.
 

modules/openshift-architecture-common-terms.adoc

@@ -141,7 +141,7 @@ private registry::
 {product-title} can use any server implementing the container image registry API as a source of the image which allows the developers to push and pull their private container images.
 
 public registry::
-{product-title} can use any server implementing the container image registry API as a source of the the image which allows the developers to push and pull their public container images.
+{product-title} can use any server implementing the container image registry API as a source of the image which allows the developers to push and pull their public container images.
 
 {op-system-base} {product-title} Cluster Manager::
 A managed service where you can install, modify, operate, and upgrade your {product-title} clusters.

modules/recommended-etcd-practices.adoc

@@ -9,7 +9,7 @@
 Because etcd writes data to disk and persists proposals on disk, its performance depends on disk performance.
 Although etcd is not particularly I/O intensive, it requires a low latency block device for optimal performance and stability. Because etcd's consensus protocol depends on persistently storing metadata to a log (WAL), etcd is sensitive to disk-write latency. Slow disks and disk activity from other processes can cause long fsync latencies.
 
-Those latencies can cause etcd to miss heartbeats, not commit new proposals to the disk on time, and ultimately experience request timeouts and temporary leader loss. High write latencies also lead to a OpenShift API slowness, which affects cluster performance. Because of these reasons, avoid colocating other workloads on the control-plane nodes.
+Those latencies can cause etcd to miss heartbeats, not commit new proposals to the disk on time, and ultimately experience request timeouts and temporary leader loss. High write latencies also lead to an OpenShift API slowness, which affects cluster performance. Because of these reasons, avoid colocating other workloads on the control-plane nodes.
 
 In terms of latency, run etcd on top of a block device that can write at least 50 IOPS of 8000 bytes long sequentially. That is, with a latency of 20ms, keep in mind that uses fdatasync to synchronize each write in the WAL. For heavy loaded clusters, sequential 500 IOPS of 8000 bytes (2 ms) are recommended. To measure those numbers, you can use a benchmarking tool, such as fio.
 

modules/rosa-sts-creating-a-cluster-with-customizations-ocm.adoc

@@ -263,7 +263,7 @@ The API endpoint cannot be changed between public and private after your cluster
 +
 Public API endpoint:: Select *Public* if you do not want to restrict access to your cluster. You can access the Kubernetes API endpoint and application routes from the internet.
 
-Private API endpoint:: Select *Private* if you want to restrict network access to to your cluster. The Kubernetes API endpoint and application routes are accessible from direct private connections only.
+Private API endpoint:: Select *Private* if you want to restrict network access to your cluster. The Kubernetes API endpoint and application routes are accessible from direct private connections only.
 +
 [IMPORTANT]
 ====

modules/vsphere-anti-affinity.adoc

@@ -8,16 +8,16 @@
 [id="anti-affinity-vsphere_{context}"]
 = Configuring vSphere DRS anti-affinity rules for control plane nodes
 
-vSphere Distributed Resource Scheduler (DRS) anti-affinity rules can be configured to support higher availability of {product-title} Control Plane nodes. Anti-affinity rules ensure that the vSphere Virtual Machines for the {product-title} Control Plane nodes are not scheduled to the same vSphere Host. 
+vSphere Distributed Resource Scheduler (DRS) anti-affinity rules can be configured to support higher availability of {product-title} Control Plane nodes. Anti-affinity rules ensure that the vSphere Virtual Machines for the {product-title} Control Plane nodes are not scheduled to the same vSphere Host.
 
 [IMPORTANT]
 ====
 * The following information applies to compute DRS only and does not apply to storage DRS.
 
-* The `govc`` command is an open-source command available from VMware; it is not available from Red Hat. The `govc` command is not supported by the Red Hat support. 
+* The `govc` command is an open-source command available from VMware; it is not available from Red Hat. The `govc` command is not supported by the Red Hat support. 
 
 * Instructions for downloading and installing `govc` are found on the VMware documentation website.
-==== 
+====
 
 // https://docs.vmware.com/en/VMware-Telco-Cloud-Operations/1.4.0/deployment-guide-140/GUID-5249E662-D792-4A1A-93E6-CF331552364C.html#:~:text=Govc%20is%20an%20open%20source,operations%20on%20the%20target%20vCenter.
 
@@ -69,4 +69,4 @@ $ govc cluster.rule.create \
   -dc MyDatacenter -cluster MyOtherCluster \
   -enable \
   -anti-affinity master-0 master-1 master-2
-----
+----

modules/ztp-configuring-disk-partitioning.adoc

@@ -6,7 +6,7 @@
 [id="ztp-configuring-disk-partitioning_{context}"]
 = Configuring disk partitioning with SiteConfig
 
-Configure disk partitioning for a managed cluster using a `SiteConfig` CR and GitOps ZTP. The  disk partition details in the `SiteConfig` CR must match the the underlying disk.
+Configure disk partitioning for a managed cluster using a `SiteConfig` CR and GitOps ZTP. The  disk partition details in the `SiteConfig` CR must match the underlying disk.
 
 [NOTE]
 ====

modules/ztp-installation-crs.adoc

@@ -29,7 +29,7 @@ The following table lists the installation CRs that are automatically applied by
 |Used with `ClusterDeployment` to generate the discovery ISO for the managed cluster.
 
 |`AgentClusterInstall`
-|Specifies details of the manged cluster configuration such as networking and the number of control plane nodes. Displays the cluster `kubeconfig` and credentials when the installation is complete.
+|Specifies details of the managed cluster configuration such as networking and the number of control plane nodes. Displays the cluster `kubeconfig` and credentials when the installation is complete.
 |Specifies the managed cluster configuration information and provides status during the installation of the cluster.
 
 |`ClusterDeployment`