Merge pull request #54463 from bergerhoffer/typo-main

Typo check before GA

Author: bergerhoffer

migrating_from_ocp_3_to_4/planning-migration-3-4.adoc

@@ -153,7 +153,7 @@ For more information, see xref:../networking/network_policy/about-network-policy
 [discrete]
 ==== OVN-Kubernetes as the default networking plug-in in Red Hat OpenShift Networking
 
-In {product-title} 3.11, OpenShift SDN was the the default networking plug-in in Red Hat OpenShift Networking. In {product-title} {product-version}, OVN-Kubernetes is now the default networking plug-in.
+In {product-title} 3.11, OpenShift SDN was the default networking plug-in in Red Hat OpenShift Networking. In {product-title} {product-version}, OVN-Kubernetes is now the default networking plug-in.
 
 For information on migrating to OVN-Kubernetes from OpenShift SDN, see xref:../networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc#migrate-from-openshift-sdn[Migrating from the OpenShift SDN network plug-in].
 

migration_toolkit_for_containers/installing-mtc-restricted.adoc

@@ -51,7 +51,7 @@ To guarantee successful data transfer in all environments, {mtc-full} ({mtc-shor
 
 ==== Manually overriding default non-root operation for data trannsfer
 
-Although running Rsync pods as non-root user works in most cases, data transfer might fail when when you run workloads as root user on the source side. {mtc-short} provides two ways to manually override default non-root operation for data transfer:
+Although running Rsync pods as non-root user works in most cases, data transfer might fail when you run workloads as root user on the source side. {mtc-short} provides two ways to manually override default non-root operation for data transfer:
 
 * Configure all migrations to run an Rsync pod as root on the destination cluster for all migrations.
 * Run an Rsync pod as root on the destination cluster per migration.

migration_toolkit_for_containers/installing-mtc.adoc

@@ -42,7 +42,7 @@ To guarantee successful data transfer in all environments, {mtc-full} ({mtc-shor
 
 ==== Manually overriding default non-root operation for data trannsfer
 
-Although running Rsync pods as non-root user works in most cases, data transfer might fail when when you run workloads as root user on the source side. {mtc-short} provides two ways to manually override default non-root operation for data transfer:
+Although running Rsync pods as non-root user works in most cases, data transfer might fail when you run workloads as root user on the source side. {mtc-short} provides two ways to manually override default non-root operation for data transfer:
 
 * Configure all migrations to run an Rsync pod as root on the destination cluster for all migrations.
 * Run an Rsync pod as root on the destination cluster per migration.

modules/cnf-topology-aware-lifecycle-manager-about-cgu-crs.adoc

@@ -150,7 +150,7 @@ When the remediation plan is successfully created, you can you set the `enable`
 
 [NOTE]
 ====
-You can only make changes to the `spec` fields if the `enable` field of the `ClusterGroupUpgrade` CR is is set to `false`.
+You can only make changes to the `spec` fields if the `enable` field of the `ClusterGroupUpgrade` CR is set to `false`.
 ====
 
 [id="validating_{context}"]

modules/olm-rukpak-registry-bundle.adoc

@@ -6,4 +6,4 @@
 [id="olm-rukpak-registry-bundle_{context}"]
 = Registry bundle spec
 
-A registry bundle, or `registry+v1` bundle, contains a set of static Kubernetes YAML manifests organized in the legacy Operator Lifecycle Manger (OLM) bundle format.
+A registry bundle, or `registry+v1` bundle, contains a set of static Kubernetes YAML manifests organized in the legacy Operator Lifecycle Manager (OLM) bundle format.

modules/overriding-default-node-ip-selection-logic.adoc

@@ -4,19 +4,19 @@
 
 :_content-type: PROCEDURE
 [id="overriding-default-node-ip-selection-logic_{context}"]
-= Optional: Overriding the default node IP selection logic 
+= Optional: Overriding the default node IP selection logic
 
-To override the default IP selection logic, you can create a hint file that includes the `NODEIP_HINT` variable to override the default IP selection logic. Creating a hint file allows you to select a specific node IP address from the interface in the subnet of the IP address specified in the `NODEIP_HINT` variable. 
+To override the default IP selection logic, you can create a hint file that includes the `NODEIP_HINT` variable to override the default IP selection logic. Creating a hint file allows you to select a specific node IP address from the interface in the subnet of the IP address specified in the `NODEIP_HINT` variable.
 
-For example, if a node has two interfaces, `eth0` with an address of `10.0.0.10/24`, and `eth1` with an address of `192.0.2.5/24`, and the default route points to `eth0` (`10.0.0.10`),the node IP address would normally use the `10.0.0.10` IP address.  
+For example, if a node has two interfaces, `eth0` with an address of `10.0.0.10/24`, and `eth1` with an address of `192.0.2.5/24`, and the default route points to `eth0` (`10.0.0.10`),the node IP address would normally use the `10.0.0.10` IP address.
 
-Users can configure the `NODEIP_HINT` variable to point at a known IP in the subnet, for example, a subnet gateway such as `192.0.2.1` so that the other subnet, `192.0.2.0/24`, is selected. As a result, the `192.0.2.5` IP address on `eth1` is used for the node. 
+Users can configure the `NODEIP_HINT` variable to point at a known IP in the subnet, for example, a subnet gateway such as `192.0.2.1` so that the other subnet, `192.0.2.0/24`, is selected. As a result, the `192.0.2.5` IP address on `eth1` is used for the node.
 
-The following procedure shows how to override the default node IP selection logic. 
+The following procedure shows how to override the default node IP selection logic.
 
 .Procedure
 
-. Add a hint file to your your `/etc/default/nodeip-configuration` file, for example: 
+. Add a hint file to your `/etc/default/nodeip-configuration` file, for example: 
 +
 [source,text]
 ----
@@ -26,7 +26,7 @@ NODEIP_HINT=192.0.2.1
 [IMPORTANT]
 ====
 * Do not use the exact IP address of a node as a hint, for example, `192.0.2.5`. Using the exact IP address of a node causes the node using the hint IP address to fail to configure correctly.
-* The IP address in the hint file is only used to determine the correct subnet. It will not receive traffic as a result of appearing in the hint file. 
+* The IP address in the hint file is only used to determine the correct subnet. It will not receive traffic as a result of appearing in the hint file.
 ====
 
 . Generate the `base-64` encoded content by running the following command:
@@ -43,7 +43,7 @@ $ echo 'NODEIP_HINT=192.0.2.1' | base64
 Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==
 ----
 
-. Activate the hint by creating a machine config manifest for both `master` and `worker` roles before deploying the cluster: 
+. Activate the hint by creating a machine config manifest for both `master` and `worker` roles before deploying the cluster:
 +
 .Master machine config manifest
 [source,yaml]
@@ -85,13 +85,13 @@ spec:
    storage:
      files:
      - contents:
-         source: data:text/plain;charset=utf-8;base64, <encoded_content> <1> 
+         source: data:text/plain;charset=utf-8;base64, <encoded_content> <1>
        mode: 0644
        overwrite: true
        path: /etc/default/nodeip-configuration
 ----
 <1> Replace `<encoded_contents>` with the  base64-encoded content of the `/etc/default/nodeip-configuration` file, for example, `Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==`.
 
-. Save the manifest to the directory where you store your cluster configuration, for example, `~/clusterconfigs`. 
+. Save the manifest to the directory where you store your cluster configuration, for example, `~/clusterconfigs`.
 
-. Deploy the cluster. 
+. Deploy the cluster.

modules/persistent-storage-csi-vol-populator.adoc

@@ -6,9 +6,9 @@
 [id="persistent-storage-csi-vol-populator_{context}"]
 = Volume populators
 
-Volume populators use the `datasource` field in a persistent volume claim (PVC) spec to to create pre-populated volumes.
+Volume populators use the `datasource` field in a persistent volume claim (PVC) spec to create pre-populated volumes.
 
 Volume population is currently enabled, and supported as a Technology Preview feature. However, {product-title} does not ship with any volume populators.
 
 :FeatureName: Volume populators
-include::snippets/technology-preview.adoc[leveloffset=+1]
+include::snippets/technology-preview.adoc[leveloffset=+1]