Merge pull request #86995 from bergerhoffer/typosweep

bergerhoffer · web-flow · commit fd6499536400 · 2025-01-14T15:00:04.000-05:00
Fixing some typos
diff --git a/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc b/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc
@@ -7,9 +7,9 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-{product-title} generates a large amount of data, such as performance metrics and logs from both the platform and the the workloads running on it. 
-As an administrator, you can use various tools to collect and analyze all the data available. 
-What follows is an outline of best practices for system engineers, architects, and administrators configuring the observability stack. 
+{product-title} generates a large amount of data, such as performance metrics and logs from both the platform and the workloads running on it. 
+As an administrator, you can use various tools to collect and analyze all the data available.
+What follows is an outline of best practices for system engineers, architects, and administrators configuring the observability stack.
 
 Unless explicitly stated, the material in this document refers to both Edge and Core deployments.
 
@@ -49,4 +49,4 @@ include::modules/telco-observability-workload-monitoring.adoc[leveloffset=+1]
 
 * xref:../../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
 
-* xref:../../../observability/monitoring/managing-alerts.adoc#managing-alerting-rules-for-user-defined-projects_managing-alerts[Managing alerting rules for user-defined projects]
+* xref:../../../observability/monitoring/managing-alerts.adoc#managing-alerting-rules-for-user-defined-projects_managing-alerts[Managing alerting rules for user-defined projects]
diff --git a/modules/ibi-create-config-iso.adoc b/modules/ibi-create-config-iso.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/ibi-edge-image-based-install.adoc 
+// * edge_computing/ibi-edge-image-based-install.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="ibi-create-config-iso_{context}"]
 = Deploying a managed {sno} cluster using the IBI Operator
 
-Create the site-specific configuration resources in the hub cluster to initiate the image-based deployment of a preinstalled host. 
+Create the site-specific configuration resources in the hub cluster to initiate the image-based deployment of a preinstalled host.
 
 When you create these configuration resources in the hub cluster, the Image Based Install (IBI) Operator generates a configuration ISO and attaches it to the target host to begin the site-specific configuration  process. When the configuration process completes, the {sno} cluster is ready.
 
@@ -64,7 +64,7 @@ $ oc create -f secret-image-registry.yaml
 .Example `host-network-config-secret.yaml` file
 [source,yaml]
 ----
-apiVersion: v1 
+apiVersion: v1
 kind: Secret
 metadata:
  name: host-network-config-secret <1>
@@ -137,7 +137,7 @@ data:
   password: <password> <11>
 ----
 <1> Specify the name for the `BareMetalHost` resource.
-<2> Specify if the host should be online. 
+<2> Specify if the host should be online.
 <3> Specify the host boot MAC address.
 <4> Specify the BMC address. You can only use bare-metal host drivers that support virtual media networking booting, for example redfish-virtualmedia and idrac-virtualmedia.
 <5> Specify the name of the bare-metal host `Secret` resource.
@@ -245,7 +245,7 @@ spec:
   baseDomain: example.com <3>
   clusterInstallRef:
     group: extensions.hive.openshift.io
-    kind: ImageClusterInstall 
+    kind: ImageClusterInstall
     name: ibi-image-install <4>
     version: v1alpha1
   clusterName: ibi-cluster <5>
@@ -283,7 +283,7 @@ spec:
   hubAcceptsClient: true <2>
 ----
 <1> Specify the name for the `ManagedCluster` resource.
-<2> Specify `true` to enable {rh-rhacm} to mange the cluster.
+<2> Specify `true` to enable {rh-rhacm} to manage the cluster.
 
 .. Create the `ManagedCluster` resource by running the following command:
 +
diff --git a/modules/microshift-automation-example-bootc-systems.adoc b/modules/microshift-automation-example-bootc-systems.adoc
@@ -15,8 +15,8 @@ As a use case, consider the following example situation in which you want to aut
 
 .Prerequisites
 
-* You have created the `10-auto-recovery.conf` and `microshift-auto-recovery.service` files as explained in the the "Automating the integration process with systemd for RPM systems" section.
-* You have created the `microshift-auto-recovery` script as explained in the the "Automating the integration process with systemd for RPM systems" section.
+* You have created the `10-auto-recovery.conf` and `microshift-auto-recovery.service` files as explained in the "Automating the integration process with systemd for RPM systems" section.
+* You have created the `microshift-auto-recovery` script as explained in the "Automating the integration process with systemd for RPM systems" section.
 
 .Procedure
 
diff --git a/modules/microshift-ingress-controller-config.adoc b/modules/microshift-ingress-controller-config.adoc
@@ -22,7 +22,7 @@ You can use detailed ingress control settings by updating the {microshift-short}
 .. Update the {microshift-short} `config.yaml` configuration file by making a copy of the provided `config.yaml.default` file in the `/etc/microshift/` directory, naming it `config.yaml` and keeping it in the source directory.
 * After you create it, the `config.yaml` file takes precedence over built-in settings. The configuration file is read every time the {microshift-short} service starts.
 
-.. Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the the `/etc/microshift/config.d/` configuration directory.
+.. Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the `/etc/microshift/config.d/` configuration directory.
 * Configuration snippet YAMLs take precedence over both built-in settings and a `config.yaml` configuration file. See the Additional resources links for more information.
 
 . Replace the default values in the `network` section of the {microshift-short} YAML with your valid values, or create a configuration snippet file with the sections you need.
@@ -164,4 +164,4 @@ $ oc get pods -n openshift-ingress
 ----
 NAME                              READY   STATUS    RESTARTS   AGE
 router-default-8649b5bf65-w29cn   1/1     Running   0          6m10s
-----
+----
diff --git a/modules/network-observability-multitenancy.adoc b/modules/network-observability-multitenancy.adoc
@@ -5,7 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-multi-tenancy_{context}"]
 = Enabling multi-tenancy in Network Observability
-Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces. 
+Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces. 
 
 For Developers, multi-tenancy is available for both Loki and Prometheus but requires different access rights.
 
@@ -42,4 +42,4 @@ $ oc adm policy add-cluster-role-to-user cluster-monitoring-view <user_group_or_
 [source,terminal]
 ----
 $ oc adm policy add-cluster-role-to-user netobserv-metrics-reader <user_group_or_name>
-----
+----
diff --git a/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc b/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc
@@ -94,7 +94,7 @@ Or:
 $ oc edit machineset <machineset> -n openshift-machine-api
 ----
 +
-After each machine is scaled up, the machine controller creates an `IPAddresssClaim` resource.
+After each machine is scaled up, the machine controller creates an `IPAddressClaim` resource.
 
 . Optional: Check that the `IPAddressClaim` resource exists in the `openshift-machine-api` namespace by entering the following command:
 +
diff --git a/modules/nw-bpfman-operator-deploy.adoc b/modules/nw-bpfman-operator-deploy.adoc
@@ -82,7 +82,7 @@ go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess
 $ oc logs <pod_name> -n go-xdp-counter
 ----
 +
-Replace `<pod_name>` with the name of a XDP program pod, such as `go-xdp-counter-ds-4m9cw`.
+Replace `<pod_name>` with the name of an XDP program pod, such as `go-xdp-counter-ds-4m9cw`.
 +
 .Example output
 [source,text]
diff --git a/modules/nw-external-dns-operator-configuration-parameters.adoc b/modules/nw-external-dns-operator-configuration-parameters.adoc
@@ -52,7 +52,7 @@ domains:
   pattern: ".*\\.otherzonedomain\\.com" <5>
 ----
 <1> Ensures that the `ExternalDNS` resource includes the domain name.
-<2> Instructs `ExtrnalDNS` that the domain matching has to be exact as opposed to regular expression match.
+<2> Instructs `ExternalDNS` that the domain matching has to be exact as opposed to regular expression match.
 <3> Defines the name of the domain.
 <4> Sets the `regex-domain-filter` flag in the `ExternalDNS` resource. You can limit possible domains by using a Regex filter.
 <5> Defines the regex pattern to be used by the `ExternalDNS` resource to filter the domains of the target zones.
diff --git a/modules/nw-sriov-networknodepolicy-object.adoc b/modules/nw-sriov-networknodepolicy-object.adoc
@@ -72,7 +72,7 @@ If you want to create virtual function on the default network interface, ensure
 +
 [NOTE]
 ====
-When `externallyManaged` is set to `true`, you must manually create the Virtual Functions (VFs) on the physical function (PF) before applying the `SriovNetworkNodePolicy` resource. If the VFs are not pre-created, the SR-IOV Network Operator's webhook will block the policy request. 
+When `externallyManaged` is set to `true`, you must manually create the Virtual Functions (VFs) on the physical function (PF) before applying the `SriovNetworkNodePolicy` resource. If the VFs are not pre-created, the SR-IOV Network Operator's webhook will block the policy request.
 
 When `externallyManaged` is set to `false`, the SR-IOV Network Operator automatically creates and manages the VFs, including resetting them if necessary.
 
@@ -114,7 +114,7 @@ When `linkType` is set to `ib`, `isRdma` is automatically set to `true` by the S
 +
 Do not set linkType to `eth` for SriovNetworkNodePolicy, because this can lead to an incorrect number of available devices reported by the device plugin.
 
-<19> Optional: To enable hardware offloading, you must set the `eSwitchMode` field to `"switchdev"`. For more information about hardware offloading , see "Configuring hardware offloading".
+<19> Optional: To enable hardware offloading, you must set the `eSwitchMode` field to `"switchdev"`. For more information about hardware offloading, see "Configuring hardware offloading".
 
 <20> Optional: To exclude advertising an SR-IOV network resource's NUMA node to the Topology Manager, set the value to `true`. The default value is `false`.
 
@@ -168,4 +168,4 @@ spec:
 
 <1> The `numVfs` field is always set to `1` when configuring the node network policy for a virtual machine.
 
-<2> The `netFilter` field must refer to a network ID when the virtual machine is deployed on {rh-openstack}. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object.
+<2> The `netFilter` field must refer to a network ID when the virtual machine is deployed on {rh-openstack}. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object.
diff --git a/modules/oadp-usecase-include-ca-cert-backup.adoc b/modules/oadp-usecase-include-ca-cert-backup.adoc
@@ -6,7 +6,7 @@
 [id="oadp-usecase-include-ca-cert-backup_{context}"]
 = Backing up an application and its self-signed CA certificate
 
-The `s3.openshift-storage.svc` service, provided by {odf-short}, uses a Transport Layer Security protocol (TLS) certificate that is signed with the self-signed service CA. 
+The `s3.openshift-storage.svc` service, provided by {odf-short}, uses a Transport Layer Security protocol (TLS) certificate that is signed with the self-signed service CA.
 
 To prevent a `certificate signed by unknown authority` error, you must include a self-signed CA certificate in the backup storage location (BSL) section of `DataProtectionApplication` custom resource (CR). For this situation, you must complete the following tasks:
 
@@ -71,11 +71,11 @@ backup-c20...41fd
 s3.openshift-storage.svc
 ----
 
-. To get the bucket credentials from the `secret` object , run the following command:
+. To get the bucket credentials from the `secret` object, run the following command:
 +
 [source,terminal]
 ----
-$ oc extract --to=- secret/test-obc 
+$ oc extract --to=- secret/test-obc
 ----
 +
 .Example output
@@ -92,8 +92,8 @@ YXf...+NaCkdyC3QPym
 [source,terminal]
 ----
 [default]
-aws_access_key_id=<AWS_ACCESS_KEY_ID> 
-aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> 
+aws_access_key_id=<AWS_ACCESS_KEY_ID>
+aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
 ----
 
 . Create the `cloud-credentials` secret with the `cloud-credentials` file content by running the following command:
@@ -142,20 +142,20 @@ spec:
         - aws
         - openshift
         - csi
-      defaultSnapshotMoveData: true 
+      defaultSnapshotMoveData: true
   backupLocations:
     - velero:
         config:
           profile: "default"
           region: noobaa
-          s3Url: https://s3.openshift-storage.svc 
-          s3ForcePathStyle: "true" 
+          s3Url: https://s3.openshift-storage.svc
+          s3ForcePathStyle: "true"
           insecureSkipTLSVerify: "false" # <1>
         provider: aws
         default: true
         credential:
           key: cloud
-          name:  cloud-credentials 
+          name:  cloud-credentials
         objectStorage:
           bucket: <bucket_name> # <2>
           prefix: oadp
@@ -169,7 +169,7 @@ spec:
 +
 [source,terminal]
 ----
-$ oc apply -f <dpa_filename> 
+$ oc apply -f <dpa_filename>
 ----
 
 . Verify that the `DataProtectionApplication` CR is created successfully by running the following command:
@@ -211,7 +211,7 @@ metadata:
 +
 [source,terminal]
 ----
-$ oc get backupstoragelocations.velero.io -n openshift-adp 
+$ oc get backupstoragelocations.velero.io -n openshift-adp
 ----
 +
 .Example output
@@ -241,7 +241,7 @@ spec:
 +
 [source,terminal]
 ----
-$ oc apply -f <backup_cr_filename> 
+$ oc apply -f <backup_cr_filename>
 ----
 
 .Verification
@@ -250,7 +250,7 @@ $ oc apply -f <backup_cr_filename>
 +
 [source,terminal]
 ----
-$ oc describe backup test-backup -n openshift-adp 
+$ oc describe backup test-backup -n openshift-adp
 ----
 +
 .Example output
@@ -273,4 +273,4 @@ Status:
   Start Timestamp:    2024-09-25T10:16:31Z
   Version:            1
 Events:               <none>
-----
+----
diff --git a/modules/telco-observability-key-performance-metrics.adoc b/modules/telco-observability-key-performance-metrics.adoc
@@ -17,11 +17,11 @@ Here are some key metrics that you should pay attention to:
 * OVN health
 * Overall cluster operator health
 
-A good rule to follow is that if you decide that a metric is important, there should be an alert for it. 
+A good rule to follow is that if you decide that a metric is important, there should be an alert for it.
 
 [NOTE]
 ====
-You can check the available metrics by runnning the following command:
+You can check the available metrics by running the following command:
 [source,terminal]
 ----
 $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk http://localhost:9090/api/v1/metadata | jq '.data
@@ -31,12 +31,12 @@ $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk ht
 [id="example-queries-promql"]
 == Example queries in PromQL
 
-The following tables show some queries that you can explore in the metrics query browser using the {product-title} console. 
+The following tables show some queries that you can explore in the metrics query browser using the {product-title} console.
 
 [NOTE]
 ====
 The URL for the console is https://<OpenShift Console FQDN>/monitoring/query-browser.
-You can get the Openshift Console FQDN by runnning the following command:
+You can get the Openshift Console FQDN by running the following command:
 [source,terminal]
 ----
 $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}'
@@ -79,7 +79,7 @@ $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].ho
 |`POST`
 |`histogram_quantile (0.99, sum by (le,managed_cluster) (sum_over_time(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver\|openshift-apiserver", verb="POST"}[60m])))`
 
-|`LIST` 
+|`LIST`
 |`histogram_quantile (0.99, sum by (le,managed_cluster) (sum_over_time(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver\|openshift-apiserver", verb="LIST"}[60m])))`
 
 |`PUT`
@@ -130,14 +130,14 @@ $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].ho
 [id="recommendations-for-storage-of-metrics"]
 == Recommendations for storage of metrics
 
-Out of the box, Prometheus does not back up saved metrics with persistent storage. 
-If you restart the Prometheus pods, all metrics data are lost. 
-You should configure the monitoring stack to use the back-end storage that is available on the platform. 
+Out of the box, Prometheus does not back up saved metrics with persistent storage.
+If you restart the Prometheus pods, all metrics data are lost.
+You should configure the monitoring stack to use the back-end storage that is available on the platform.
 To meet the high IO demands of Prometheus you should use local storage.
 
-For Telco core clusters, you can use the Local Storage Operator for persistent storage for Prometheus. 
+For Telco core clusters, you can use the Local Storage Operator for persistent storage for Prometheus.
 
 {odf-first}, which deploys a ceph cluster for block, file, and object storage, is also a suitable candidate for a Telco core cluster.
 
-To keep system resource requirements low on a RAN {sno} or far edge cluster, you should not provision backend storage for the monitoring stack. 
-Such clusters forward all metrics to the hub cluster where you can provision a third party monitoring platform.
+To keep system resource requirements low on a RAN {sno} or far edge cluster, you should not provision backend storage for the monitoring stack.
+Such clusters forward all metrics to the hub cluster where you can provision a third party monitoring platform.
diff --git a/modules/telco-troubleshooting-mco-purpose.adoc b/modules/telco-troubleshooting-mco-purpose.adoc
@@ -14,6 +14,6 @@ You must consider these minor components and how the MCO can help you manage you
 
 [IMPORTANT]
 ====
-You must use the the MCO to perform all changes on worker or control plane nodes.
+You must use the MCO to perform all changes on worker or control plane nodes.
 Do not manually make changes to {op-system} or node files.
-====
+====
diff --git a/modules/virt-configuring-vm-use-usb-device.adoc b/modules/virt-configuring-vm-use-usb-device.adoc
@@ -17,7 +17,7 @@ You can configure virtual machine (VM) access to a USB device. This configuratio
 $ oc /dev/serial/by-id/usb-VENDOR_device_name
 ----
 
-. Open the virtual machine instance custom resource (CR) by running the following commmand:
+. Open the virtual machine instance custom resource (CR) by running the following command:
 +
 [source,terminal]
 ----
@@ -44,4 +44,3 @@ spec:
 # ...
 ----
 <1> The name of the USB device.
-
diff --git a/modules/virt-enabling-usb-host-passthrough.adoc b/modules/virt-enabling-usb-host-passthrough.adoc
@@ -23,7 +23,7 @@ You specify a resource name and USB device name for each device you want first t
 $ lsusb
 ----
 
-. Open the HCO CR by running the following commmand:
+. Open the HCO CR by running the following command:
 +
 [source,terminal]
 ----
@@ -57,4 +57,4 @@ spec:
 ----
 <1> Lists the host devices that have permission to be used in the cluster.
 <2> Lists the available USB devices.
-<3> Uses `resourceName: deviceName` for each device you want to add and assign to the VM. In this example, the resource is bound to three devices, each of which is identified by `vendor` and `product` and is known as a `selector`.
+<3> Uses `resourceName: deviceName` for each device you want to add and assign to the VM. In this example, the resource is bound to three devices, each of which is identified by `vendor` and `product` and is known as a `selector`.
diff --git a/networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc b/networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc
diff --git a/windows_containers/enabling-windows-container-workloads.adoc b/windows_containers/enabling-windows-container-workloads.adoc

Original file line number	Diff line number	Diff line change
`@@ -94,7 +94,7 @@ Or:`
`94`	`94`	`$ oc edit machineset <machineset> -n openshift-machine-api`
`95`	`95`	`----`
`96`	`96`	`+`
`97`		-After each machine is scaled up, the machine controller creates an `IPAddresssClaim` resource.
	`97`	+After each machine is scaled up, the machine controller creates an `IPAddressClaim` resource.
`98`	`98`
`99`	`99`	. Optional: Check that the `IPAddressClaim` resource exists in the `openshift-machine-api` namespace by entering the following command:
`100`	`100`	`+`
Original file line number	Diff line number	Diff line change
`@@ -82,7 +82,7 @@ go-xdp-counter-example xdp_stats {} ReconcileSuccess`
`82`	`82`	`$ oc logs <pod_name> -n go-xdp-counter`
`83`	`83`	`----`
`84`	`84`	`+`
`85`		-Replace `<pod_name>` with the name of a XDP program pod, such as `go-xdp-counter-ds-4m9cw`.
	`85`	+Replace `<pod_name>` with the name of an XDP program pod, such as `go-xdp-counter-ds-4m9cw`.
`86`	`86`	`+`
`87`	`87`	`.Example output`
`88`	`88`	`[source,text]`