Merge pull request #42771 from bergerhoffer/typocheck

Fixing some typos

Author: bergerhoffer

modules/azure-stack-hub-internal-ca.adoc

@@ -31,4 +31,4 @@ spec:
     name: user-ca-bundle
 status: {}
 ----
-. Optional: Back up the `manifests/ cluster-proxy-01-config.yaml` file. The installation program consumes the `manifests/` directory when you you deploy the cluster.
+. Optional: Back up the `manifests/ cluster-proxy-01-config.yaml` file. The installation program consumes the `manifests/` directory when you deploy the cluster.

modules/bmo-about-the-baremetalhost-resource.adoc

@@ -45,7 +45,7 @@ a| The `bmc` configuration setting contains the connection information for the b
 | The boot mode of the host. It defaults to `UEFI`, but it can also be set to `legacy` for BIOS boot, or `UEFISecureBoot`.
 
 | `consumerRef`
-| A reference to another resource that is using the host. It could be empty if another resource is not currently using the host. For example, a `Machine` resource might use the host when the the `machine-api` is using the host.
+| A reference to another resource that is using the host. It could be empty if another resource is not currently using the host. For example, a `Machine` resource might use the host when the `machine-api` is using the host.
 
 | `description`
 | A human-provided string to help identify the host.

modules/eco-poison-pill-operator-about.adoc

@@ -6,9 +6,9 @@
 [id="about-poison-pill-operator_{context}"]
 = About the Poison Pill Operator
 
-The Poison Pill Operator runs on the cluster nodes and reboots nodes that are identified as unhealthy. The Operator uses the `MachineHealthCheck` controller to detect the health of a node in the cluster. When a node is identified as unhealthy, the `MachineHealthCheck` resource creates the `PoisonPillRemediation` custom resource (CR), which triggers the Poison Pill Operator. 
+The Poison Pill Operator runs on the cluster nodes and reboots nodes that are identified as unhealthy. The Operator uses the `MachineHealthCheck` controller to detect the health of a node in the cluster. When a node is identified as unhealthy, the `MachineHealthCheck` resource creates the `PoisonPillRemediation` custom resource (CR), which triggers the Poison Pill Operator.
 
-The Poison Pill Operator minimizes downtime for stateful applications and restores compute capacity if transient failures occur. You can use this Operator regardless of the management interface, such as IPMI or an API to provision a node, and regardless of of the cluster installation type, such as Installer Provisioned Infrastructure (IPI) or User Provisioned Infrastructure (UPI).
+The Poison Pill Operator minimizes downtime for stateful applications and restores compute capacity if transient failures occur. You can use this Operator regardless of the management interface, such as IPMI or an API to provision a node, and regardless of the cluster installation type, such as installer-provisioned infrastructure or user-provisioned infrastructure.
 
 [id="understanding-poison-pill-operator-config_{context}"]
 == Understanding the Poison Pill Operator configuration
@@ -31,7 +31,7 @@ spec:
   watchdogFilePath: /test/watchdog1 <2>
   isSoftwareRebootEnabled: true <3>
   apiServerTimeout: 15s <4>
-  apiCheckInterval: 5s <5>  
+  apiCheckInterval: 5s <5>
   maxApiErrorThreshold: 3 <6>
   peerApiServerTimeout: 5s <7>
   peerDialTimeout: 5s <8>
@@ -42,10 +42,10 @@ spec:
 <1> Specify the timeout duration for the surviving peer, after which the Operator can assume that an unhealthy node has been rebooted. The Operator automatically calculates the lower limit for this value. However, if different nodes have different watchdog timeouts, you must change this value to a higher value.
 <2> Specify the file path of the watchdog device in the nodes. If a watchdog device is unavailable, the `PoisonPillConfig` CR uses a software reboot.
 <3> Specify if you want to enable software reboot of the unhealthy nodes. By default, the value of `isSoftwareRebootEnabled` is set to `true`. To disable the software reboot, set the parameter value to `false`.
-<4> Specify the timeout duration to check connectivity with each API server. When this duration elapses, the Operator starts remediation. 
+<4> Specify the timeout duration to check connectivity with each API server. When this duration elapses, the Operator starts remediation.
 <5> Specify the frequency to check connectivity with each API server.
 <6> Specify a threshold value. After reaching this threshold, the node starts contacting its peers.
 <7> Specify the timeout duration to connect with the peer API server.
 <8> Specify the timeout duration for establishing connection with the peer.
 <9> Specify the timeout duration to get a response from the peer.
-<10> Specify the frequency to update peer information, such as IP address.
+<10> Specify the frequency to update peer information, such as IP address.

modules/installation-azure-user-infra-uploading-rhcos.adoc

@@ -159,7 +159,7 @@ $ curl -O -L ${COMPRESSED_VHD_URL}
 ====
 The decompressed VHD file is approximately 16 GB, so be sure that your host system has 16 GB of free space available. The VHD file can be deleted once you have uploaded it.
 ====
-. Upload the the local VHD to the Azure Stack Hub environment, making sure that the blob is publicly available. For example, you can upload the VHD to a blob using the `az` cli or the web portal.
+. Upload the local VHD to the Azure Stack Hub environment, making sure that the blob is publicly available. For example, you can upload the VHD to a blob using the `az` cli or the web portal.
 endif::ash-ipi[]
 
 ifeval::["{context}" == "installing-azure-user-infra"]

modules/kube-apiserver-operator.adoc

@@ -19,7 +19,7 @@ link:https://github.com/openshift/cluster-kube-apiserver-operator[openshift-kube
 == CRDs
 
 * `kubeapiservers.operator.openshift.io`
-** Scope: Cluser
+** Scope: Cluster
 ** CR: `kubeapiserver`
 ** Validation: Yes
 

modules/machineset-gcp-enabling-gpu-support.adoc

@@ -87,7 +87,7 @@ GPUs for graphics workloads are not supported.
       onHostMaintenance: Terminate <2>
       restartPolicy: Always <3>
 ----
-<1> Specify the machine type. Ensure that the machine type is included in the the A2 machine series.
+<1> Specify the machine type. Ensure that the machine type is included in the A2 machine series.
 <2> When using GPU support, you must set `onHostMaintenance` to `Terminate`.
 <3> Specify the restart policy for machines deployed by the machine set. Allowed values are `Always` or `Never`.
 +

modules/nodes-pods-autoscaling-best-practices-hpa.adoc

@@ -12,7 +12,7 @@ Missing resource request values can affect the optimal performance of the HPA.
 
 .Configure the cool down period
 During horizontal pod autoscaling, there might be a rapid scaling of events without a time gap. Configure the cool down period to prevent frequent replica fluctuations.
-You can specify a cool down period by configuring the `stabilizationWindowSeconds` field. The stabilization window is used to restrict the the fluctuation of replicas count when the metrics used for scaling keep fluctuating.
+You can specify a cool down period by configuring the `stabilizationWindowSeconds` field. The stabilization window is used to restrict the fluctuation of replicas count when the metrics used for scaling keep fluctuating.
 The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale.
 
 For example, a stabilization window is specified for the `scaleDown` field:

modules/serverless-autoscaling-dashboard-navigating.adoc

@@ -6,7 +6,7 @@
 [id="serverless-autoscaling-dashboard-navigating_{context}"]
 = Navigating to the autoscaling dashboard
 
-You can use the following steps to navigate to the autoscaling dashboard in the the {product-title} web console.
+You can use the following steps to navigate to the autoscaling dashboard in the {product-title} web console.
 
 .Prerequisites