Merge pull request #99927 from bergerhoffer/typo-check

bergerhoffer · web-flow · commit 288cefe5cf83 · 2025-10-06T13:52:38.000-04:00
Fixing some typos
diff --git a/hosted_control_planes/hosted-control-planes-release-notes.adoc b/hosted_control_planes/hosted-control-planes-release-notes.adoc
@@ -90,7 +90,7 @@ As a result, the `HostedCluster` resource can be deployed successfully, even in
 
 * Previously, the process to validate the container image architecture did not pass through the image metadata provider. As a consequence, image overrides did not take effect, and disconnected deployments failed. In this release, the methods for the image metadata provider are modified to allow multi-architecture validations, and are propagated through all components for image validation. As a result, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44655[OCPBUGS-44655])
 
-* Previously, the `--goaway-chance` flag for the the Kubernetes API Server was not configurable. The default value for the flag was `0`. With this release, you can change the value for the `--goaway-chance` flag by adding an annotation to the `HostedCluster` custom resource. (link:https://issues.redhat.com/browse/OCPBUGS-54863[OCPBUGS-54863])
+* Previously, the `--goaway-chance` flag for the Kubernetes API Server was not configurable. The default value for the flag was `0`. With this release, you can change the value for the `--goaway-chance` flag by adding an annotation to the `HostedCluster` custom resource. (link:https://issues.redhat.com/browse/OCPBUGS-54863[OCPBUGS-54863])
 
 * Previously, on instances of Red{nbsp}Hat OpenShift on {ibm-cloud-title} that are based on {hcp}, in non-OVN clusters, the Cluster Network Operator could not patch service monitors and Prometheus rules in the `monitoring.coreos.com` API group. As a consequence, the Cluster Network Operator logs showed permissions errors and "could not apply" messages. With this release, permissions for service monitors and Prometheus rules are added in the Cluster Network Operator for non-OVN clusters. As a result, the Cluster Network Operator logs no longer show permissions errors. (link:https://issues.redhat.com/browse/OCPBUGS-54178[OCPBUGS-54178])
 
diff --git a/modules/coo-troubleshooting-ui-plugin-using.adoc b/modules/coo-troubleshooting-ui-plugin-using.adoc
@@ -27,7 +27,7 @@ Other signal types require optional components to be installed:
 ====
 .Procedure
 
-. In the the web console, go to *Observe* -> *Alerting* and then select an alert. If the alert has correlated items, a **Troubleshooting Panel** link will appear above the chart on the alert detail page.
+. In the web console, go to *Observe* -> *Alerting* and then select an alert. If the alert has correlated items, a **Troubleshooting Panel** link will appear above the chart on the alert detail page.
 +
 image::coo-troubleshooting-panel-link.png[Troubleshooting Panel link]
 +
@@ -82,4 +82,4 @@ Setting a large value in a large cluster might cause the query to fail, if the n
 
 **** `netflow:network` representing any network observability network event.
 
-**** `log:__LOG_TYPE__` representing stored logs, where `__LOG_TYPE__` must be one of `application`, `infrastructure` or `audit`.
+**** `log:__LOG_TYPE__` representing stored logs, where `__LOG_TYPE__` must be one of `application`, `infrastructure` or `audit`.
diff --git a/modules/dr-restoring-cluster-state.adoc b/modules/dr-restoring-cluster-state.adoc
@@ -6,12 +6,12 @@
 
 // Contributors: The documentation for this section changed drastically for 4.18+.
 
-// Contributors: Some changes for the `etcd` restore procedure are only valid for 4.14+. 
-// In the 4.14+ documentation, OVN-K requires different steps because there is no centralized OVN 
-// control plane to be converted. For more information, see PR #64939. 
+// Contributors: Some changes for the `etcd` restore procedure are only valid for 4.14+.
+// In the 4.14+ documentation, OVN-K requires different steps because there is no centralized OVN
+// control plane to be converted. For more information, see PR #64939.
 // Do not cherry pick from "main" to "enterprise-4.12" or "enterprise-4.13" because the cherry pick
-// procedure is different for these versions. Instead, open a separate PR for 4.13 and 
-// cherry pick to 4.12 or make the updates directly in 4.12.  
+// procedure is different for these versions. Instead, open a separate PR for 4.13 and
+// cherry pick to 4.12 or make the updates directly in 4.12.
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-scenario-2-restoring-cluster-state_{context}"]
@@ -77,7 +77,7 @@ $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
 
 . Exit the SSH session.
 
-. Once the API responds, turn off the etcd Operator quorum guard by runnning the following command:
+. Once the API responds, turn off the etcd Operator quorum guard by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/machine-config-pin-preload-images.adoc b/modules/machine-config-pin-preload-images.adoc
@@ -6,9 +6,9 @@
 [id="machine-config-pin-preload-images_{context}"]
 = Pinning images
 
-You can pin images to your nodes by using a `PinnedImageSet` custom resource (CR). The pinned image set defines the list of images to pre-load and the machine config pool to which the images should be pinned. 
+You can pin images to your nodes by using a `PinnedImageSet` custom resource (CR). The pinned image set defines the list of images to pre-load and the machine config pool to which the images should be pinned.
 
-The images are stored in the the `/etc/crio/crio.conf.d/50-pinned-images` file on the nodes. 
+The images are stored in the `/etc/crio/crio.conf.d/50-pinned-images` file on the nodes. 
 
 [NOTE]
 ====
diff --git a/modules/microshift-verify-container-signatures-sigstore.adoc b/modules/microshift-verify-container-signatures-sigstore.adoc
@@ -60,7 +60,7 @@ $ sudo curl -sL https://access.redhat.com/security/data/63405576.txt -o /etc/con
 }
 ----
 
-. Configure Red Hat remote registries to use sigstore attachments when pulling images to the local storage, by editing the `/etc/containers/registries.d/registry.redhat.io.yaml`` file to contain the following configuration:
+. Configure Red Hat remote registries to use sigstore attachments when pulling images to the local storage, by editing the `/etc/containers/registries.d/registry.redhat.io.yaml` file to contain the following configuration:
 +
 [source,terminal]
 ----
diff --git a/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc b/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc
@@ -18,7 +18,7 @@ include::snippets/unified-perspective-web-console.adoc[]
 
 .Procedure
 
-. In the the *Developer* perspective of the {product-title} web console, click *Observe* and go to the *Dashboards* tab.
+. In the *Developer* perspective of the {product-title} web console, click *Observe* and go to the *Dashboards* tab.
 
 . Select a project from the *Project:* drop-down list.
 
diff --git a/modules/network-observability-filtering-ebpf-rule.adoc b/modules/network-observability-filtering-ebpf-rule.adoc
@@ -52,7 +52,7 @@ spec:
 ----
 <1> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
 <2> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
-<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use `0.0.0.0/0` for IPv4 or ``::/0` for IPv6.
+<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
 <4> To define the sampling rate for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
 <5> To filter flows by Peer IP CIDR, set the `peerCIDR` parameter.
 
@@ -86,4 +86,4 @@ spec:
 <2> To report packet drops for each network flow, add the `PacketDrop` value to the `spec.agent.ebpf.features` list.
 <3> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
 <4> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
-<5> To filter flows containing drops, set `pktDrops` to `true`.
+<5> To filter flows containing drops, set `pktDrops` to `true`.
diff --git a/modules/persistent-storage-csi-azure-file-static-provisioning-procedure.adoc b/modules/persistent-storage-csi-azure-file-static-provisioning-procedure.adoc
@@ -54,28 +54,28 @@ spec:
     - uid=0
     - gid=0
     - cache=strict  <6>
-    - nosharesock  <7> 
-    - actimeo=30  <8> 
+    - nosharesock  <7>
+    - actimeo=30  <8>
     - nobrl  <9>
   csi:
     driver: file.csi.azure.com
     volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}" <10>
     volumeAttributes:
-      shareName: EXISTING_FILE_SHARE_NAME  <11> 
+      shareName: EXISTING_FILE_SHARE_NAME  <11>
     nodeStageSecretRef:
       name: azure-secret <12>
       namespace: <my-namespace> <13>
 ----
 <1> Volume size.
-<2> Access mode. Defines the read-write and mount permissions. For more information, under _Additional Resources_, see _Access modes_.
+<2> Access mode. Defines the read-write and mount permissions. For more information, under _Additional resources_, see _Access modes_.
 <3> Reclaim policy. Tells the cluster what to do with the volume after it is released. Accepted values are `Retain`, `Recycle`, or `Delete`.
 <4> Storage class name. This name is used by the PVC to bind to this specific PV. For static provisioning, a `StorageClass` object does not need to exist, but the name in the PV and PVC must match.
 <5> Modify this permission if you want to enhance the security.
 <6> Cache mode. Accepted values are `none`, `strict`, and `loose`. The default is `strict`.
 <7> Use to reduce the probability of a reconnect race.
-<8> The time (in seconds) that the CIFS client caches attributes of a file or directory before it requests attribute information from a server. 
+<8> The time (in seconds) that the CIFS client caches attributes of a file or directory before it requests attribute information from a server.
 <9> Disables sending byte range lock requests to the server, and for applications which have challenges with POSIX locks.
-<10> Ensure that `volumeHandle` is unique across the cluster. The `resource-group-name` is the Azure resource group where the storage account resides. 
+<10> Ensure that `volumeHandle` is unique across the cluster. The `resource-group-name` is the Azure resource group where the storage account resides.
 <11> File share name. Use only the file share name; do not use full path.
 <12> Provide the name of the secret created in step 1 of this procedure. In this example, it is _azure-secret_.
 <13> The namespace that the secret was created in. This must be the namespace where the PV is consumed.
@@ -103,7 +103,7 @@ spec:
 <2> Namespace for the PVC.
 <3> The name of the PV that you created in the previous step.
 <4> Storage class name. This name is used by the PVC to bind to this specific PV. For static provisioning, a `StorageClass` object does not need to exist, but the name in the PV and PVC must match.
-<5> Access mode. Defines the requested read-write access for the PVC. Claims use the same conventions as volumes when requesting storage with specific access modes. For more information, under _Additional Resources_, see _Access modes_.
+<5> Access mode. Defines the requested read-write access for the PVC. Claims use the same conventions as volumes when requesting storage with specific access modes. For more information, under _Additional resources_, see _Access modes_.
 <6> PVC size.
 
 . Ensure that the PVC is created and in `Bound` status after a while by running the following command:
diff --git a/modules/persistent-storage-csi-drivers-supported.adoc b/modules/persistent-storage-csi-drivers-supported.adoc
@@ -25,7 +25,7 @@ endif::openshift-rosa,openshift-rosa-hcp[]
 
 The following table describes the CSI drivers that are
 ifndef::openshift-dedicated[]
-installed with {product-title}, 
+installed with {product-title},
 endif::openshift-dedicated[]
 supported by {product-title}, and which CSI features they support, such as volume snapshots and resize.
 
@@ -35,7 +35,7 @@ ifndef::openshift-rosa,openshift-rosa-hcp[]
 If your CSI driver is not listed in the following table, you must follow the installation instructions provided by your CSI storage vendor to use their supported CSI features.
 ====
 
-For a list of third-party-certified CSI drivers, see the _Red Hat ecosystem portal_ under _Additional Resources_.
+For a list of third-party-certified CSI drivers, see the _Red Hat ecosystem portal_ under _Additional resources_.
 
 endif::openshift-rosa,openshift-rosa-hcp[]
 ifdef::openshift-rosa,openshift-rosa-hcp,openshift-aro[]
@@ -46,32 +46,32 @@ endif::openshift-rosa,openshift-rosa-hcp,openshift-aro[]
 [cols=",^v,^v,^v,^v,^v,^v width="100%",options="header"]
 |===
 |CSI driver |CSI volume snapshots  |CSI volume group snapshots ^[1]^ |CSI cloning  |CSI resize |Inline ephemeral volumes
-|AWS EBS | ✅ |  |  | ✅| 
-|AWS EFS |  |  |  |  | 
+|AWS EBS | ✅ |  |  | ✅|
+|AWS EFS |  |  |  |  |
 ifndef::openshift-rosa,openshift-rosa-hcp[]
 |Google Compute Platform (GCP) persistent disk (PD)|  ✅|  |✅^[2]^ | ✅|
-|GCP Filestore | ✅ |  | | ✅|  
+|GCP Filestore | ✅ |  | | ✅|
 endif::openshift-rosa,openshift-rosa-hcp[]
 ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
-|{ibm-power-server-name} Block |   |  |   | ✅ |  
-|{ibm-cloud-name} Block | ✅^[3]^ |  |   | ✅^[3]^|  
+|{ibm-power-server-name} Block |   |  |   | ✅ |
+|{ibm-cloud-name} Block | ✅^[3]^ |  |   | ✅^[3]^|
 endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
-|LVM Storage | ✅ |  | ✅ | ✅ |  
+|LVM Storage | ✅ |  | ✅ | ✅ |
 ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
-|Microsoft Azure Disk | ✅ |  | ✅ | ✅|  
-|Microsoft Azure Stack Hub | ✅ |  | ✅ | ✅|  
+|Microsoft Azure Disk | ✅ |  | ✅ | ✅|
+|Microsoft Azure Stack Hub | ✅ |  | ✅ | ✅|
 |Microsoft Azure File | ✅^[4]^  |  | ✅^[4]^ | ✅| ✅
-|OpenStack Cinder | ✅ |  | ✅ | ✅|  
-|OpenShift Data Foundation | ✅ | ✅ | ✅ | ✅|  
-|OpenStack Manila | ✅ |  |   | ✅  |  
+|OpenStack Cinder | ✅ |  | ✅ | ✅|
+|OpenShift Data Foundation | ✅ | ✅ | ✅ | ✅|
+|OpenStack Manila | ✅ |  |   | ✅  |
 |Shared Resource |   |  |   |   | ✅
-|CIFS/SMB |   |  | ✅  |   |   
-|VMware vSphere | ✅^[5]^ |  |   | ✅^[6]^|  
+|CIFS/SMB |   |  | ✅  |   |
+|VMware vSphere | ✅^[5]^ |  |   | ✅^[6]^|
 endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 |===
 ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 --
-1. 
+1.
 
 :FeatureName: CSI volume group snapshots
 include::snippets/technology-preview.adoc[leveloffset=+1]
@@ -93,7 +93,7 @@ include::snippets/technology-preview.adoc[leveloffset=+1]
 :FeatureName: Azure File CSI cloning and snapshot
 include::snippets/technology-preview.adoc[leveloffset=+1]
 
-5. 
+5.
 
 * Requires vSphere version 7.0 Update 3 or later for both vCenter Server and ESXi.
 
@@ -103,4 +103,4 @@ include::snippets/technology-preview.adoc[leveloffset=+1]
 
 * Online expansion is supported from vSphere version 7.0 Update 2 and later.
 --
-endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
diff --git a/modules/rosa-sdpolicy-platform.adoc b/modules/rosa-sdpolicy-platform.adoc
@@ -163,4 +163,4 @@ Red{nbsp}Hat workloads typically refer to Red{nbsp}Hat-provided Operators made a
 
 [id="rosa-sdpolicy-kubernetes-operator_{context}"]
 == Kubernetes Operator support
-All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored nor managed by by Red{nbsp}Hat SRE. Operators authored by Red{nbsp}Hat are supported by Red{nbsp}Hat.
+All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored nor managed by Red{nbsp}Hat SRE. Operators authored by Red{nbsp}Hat are supported by Red{nbsp}Hat.
diff --git a/modules/virt-creating-fusionaccess-cr.adoc b/modules/virt-creating-fusionaccess-cr.adoc
@@ -6,7 +6,7 @@
 [id="creating-fusionaccess-cr_{context}"]
 = Creating the FusionAccess CR
 
-After installing the {FusionSAN} Operator and creating a Kubernetes pull secret, you must create the `FusionAccess` custome resource (CR).
+After installing the {FusionSAN} Operator and creating a Kubernetes pull secret, you must create the `FusionAccess` custom resource (CR).
 
 Creating the `FusionAccess` CR triggers the installation of the correct version of IBM Storage Scale and detects worker nodes with shared LUNs.
 
diff --git a/networking/network_security/network-policy-apis.adoc b/networking/network_security/network-policy-apis.adoc
@@ -17,7 +17,7 @@ Policies defined using the `AdminNetworkPolicy` API take precedence over all oth
 +
 Policies defined using the `BaselineAdminNetworkPolicy` API apply only when no other network policy overrides them. When you use the `AdminNetworkPolicy` API to delegate an aspect of network policy to the namespace-scoped `NetworkPolicy`, you should also define a sensible minimum restriction in the `BaselineAdminNetworkPolicy`. This ensures a baseline level of network security at the cluster level in case the `NetworkPolicy` for a namespace does not provide sufficient protection.
 
-Namespace-scoped network policy:: Application developers and namespace tenants can use the `NetworkPolicy` API to define network policy rules for a specific namespace. Rules in the `NetworkPolicy` for a namespace take precedence over cluster-wide rules configured using the BaselineAdminNetworkPolicy API, or for a cluster-wide rule that that has been delegated or "passed" from the cluster-wide `AdminNetworkPolicy` API. 
+Namespace-scoped network policy:: Application developers and namespace tenants can use the `NetworkPolicy` API to define network policy rules for a specific namespace. Rules in the `NetworkPolicy` for a namespace take precedence over cluster-wide rules configured using the BaselineAdminNetworkPolicy API, or for a cluster-wide rule that has been delegated or "passed" from the cluster-wide `AdminNetworkPolicy` API. 
 
 [discrete]
 == How network policy is evaluated and applied
diff --git a/rosa_release_notes/rosa-release-notes.adoc b/rosa_release_notes/rosa-release-notes.adoc
@@ -204,7 +204,7 @@ endif::openshift-rosa-hcp[]
 +
 Elevated access requests to ROSA clusters and the corresponding cloud accounts can be created by Red{nbsp}Hat SRE either in response to a customer-initiated support ticket or in response to alerts received by a Red{nbsp}Hat SRE, as part of the standard incident response process. For more information, see xref:../support/approved-access.adoc#approved-access[Approved Access].
 
-* **`rosa`` command enhancement.** The `rosa describe` command has a new optional argument, `--get-role-policy-bindings`. This new argument allows users to view the policies attached to STS roles assigned to the selected cluster. For more information, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-describe-cluster_rosa-managing-objects-cli[describe cluster].
+* **`rosa` command enhancement.** The `rosa describe` command has a new optional argument, `--get-role-policy-bindings`. This new argument allows users to view the policies attached to STS roles assigned to the selected cluster. For more information, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-describe-cluster_rosa-managing-objects-cli[describe cluster].
 
 * **Expanded customer-managed policy capabilities.** You can now attach customer-managed policies to the IAM roles required to run {product-title} clusters. Furthermore, these customer-managed policies, including the permissions attached to those policies, are not modified during cluster or role upgrades. For more information, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-aws-customer-managed-policies_rosa-sts-about-iam-resources[Customer-managed policies].
 
diff --git a/security/zero_trust_workload_identity_manager/zero-trust-manager-release-notes.adoc b/security/zero_trust_workload_identity_manager/zero-trust-manager-release-notes.adoc
@@ -99,4 +99,4 @@ This initial release of {zero-trust-full} is a Technology Preview. This version
 
 * This version operates using a fixed configuration. User-defined configurations are not allowed.
 
-* The log level of operands are not configurable. The default value is `DEBUG``.
+* The log level of operands are not configurable. The default value is `DEBUG`.

Original file line number	Diff line number	Diff line change
`@@ -27,7 +27,7 @@ Other signal types require optional components to be installed:`
`27`	`27`	`====`
`28`	`28`	`.Procedure`
`29`	`29`
`30`		`-. In the the web console, go to Observe -> Alerting and then select an alert. If the alert has correlated items, a Troubleshooting Panel link will appear above the chart on the alert detail page.`
	`30`	`+. In the web console, go to Observe -> Alerting and then select an alert. If the alert has correlated items, a Troubleshooting Panel link will appear above the chart on the alert detail page.`
`31`	`31`	`+`
`32`	`32`	`image::coo-troubleshooting-panel-link.png[Troubleshooting Panel link]`
`33`	`33`	`+`
`@@ -82,4 +82,4 @@ Setting a large value in a large cluster might cause the query to fail, if the n`
`82`	`82`
`83`	`83`	**** `netflow:network` representing any network observability network event.
`84`	`84`
`85`		-**** `log:__LOG_TYPE__` representing stored logs, where `__LOG_TYPE__` must be one of `application`, `infrastructure` or `audit`.
	`85`	+**** `log:__LOG_TYPE__` representing stored logs, where `__LOG_TYPE__` must be one of `application`, `infrastructure` or `audit`.
Original file line number	Diff line number	Diff line change
`@@ -60,7 +60,7 @@ $ sudo curl -sL https://access.redhat.com/security/data/63405576.txt -o /etc/con`
`60`	`60`	`}`
`61`	`61`	`----`
`62`	`62`
`63`		-. Configure Red Hat remote registries to use sigstore attachments when pulling images to the local storage, by editing the `/etc/containers/registries.d/registry.redhat.io.yaml`` file to contain the following configuration:
	`63`	+. Configure Red Hat remote registries to use sigstore attachments when pulling images to the local storage, by editing the `/etc/containers/registries.d/registry.redhat.io.yaml` file to contain the following configuration:
`64`	`64`	`+`
`65`	`65`	`[source,terminal]`
`66`	`66`	`----`