Merge pull request #87976 from bergerhoffer/418-typo-check

Fixing some typos

Author: bergerhoffer

modules/nodes-pods-vertical-autoscaler-custom-resource.adoc

@@ -8,7 +8,7 @@
 
 The Vertical Pod Autoscaler Operator (VPA) can update not only built-in resources such as deployments or stateful sets, but also custom resources that manage pods.
 
-In order to use the VPA with a custom resource, when you create the the `CustomResourceDefinition` (CRD) object, you must configure the `labelSelectorPath` field in the `/scale` subresource. The `/scale` subresource creates a `Scale` object. The `labelSelectorPath` field defines the JSON path inside the custom resource that corresponds to `Status.Selector` in the `Scale` object and in the custom resource. The following is an example of a `CustomResourceDefinition` and a `CustomResource` that fulfills these requirements, along with a `VerticalPodAutoscaler` definition that targets the custom resource. The following example shows the `/scale` subresource contract. 
+In order to use the VPA with a custom resource, when you create the `CustomResourceDefinition` (CRD) object, you must configure the `labelSelectorPath` field in the `/scale` subresource. The `/scale` subresource creates a `Scale` object. The `labelSelectorPath` field defines the JSON path inside the custom resource that corresponds to `Status.Selector` in the `Scale` object and in the custom resource. The following is an example of a `CustomResourceDefinition` and a `CustomResource` that fulfills these requirements, along with a `VerticalPodAutoscaler` definition that targets the custom resource. The following example shows the `/scale` subresource contract. 
 
 [NOTE]
 ====
@@ -61,7 +61,7 @@ spec:
 ----
 <1> Specifies the JSON path that corresponds to `status.selector` field of the custom resource object.
 
-.Example custom CR 
+.Example custom CR
 [source,yaml]
 ----
 apiVersion: testing.openshift.io/v1

modules/nodes-sigstore-configure-cluster-policy.adoc

@@ -113,8 +113,8 @@ spec:
 <6> For a Fulcio certificate policy, the following parameters are required:
 * `fulcioCAData`: Specifies a base64-encoded Fulcio certificate in the PEM format. The maximum length is 8192 characters.
 * `fulcioSubject`: Specifies the OIDC issuer and the email of the Fulcio authentication configuration.
-<7> Specifies a base64-encoded Rekor public key in the PEM format. This parameter is required when when the `policyType` is `FulcioCAWithRekor`. The maximum length is 8192 characters.
-<8> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity. 
+<7> Specifies a base64-encoded Rekor public key in the PEM format. This parameter is required when the `policyType` is `FulcioCAWithRekor`. The maximum length is 8192 characters.
+<8> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity.
 * `MatchRepoDigestOrExact`.
 * `MatchRepository`.
 * `ExactRepository`. The `exactRepository` parameter must be specified.

modules/nodes-sigstore-configure-image-policy.adoc

@@ -131,7 +131,7 @@ spec:
 <7> For a Fulcio certificate policy, the following parameters are required:
 * `fulcioCAData`: Specifies a base64-encoded Fulcio certificate in the PEM format. The maximum length is 8192 characters.
 * `fulcioSubject`: Specifies the OIDC issuer and the email of the Fulcio authentication configuration.
-<8> Specifies a base64-encoded Rekor public key in the PEM format. This parameter is required when when the `policyType` is `FulcioCAWithRekor`. The maximum length is 8192 characters.
+<8> Specifies a base64-encoded Rekor public key in the PEM format. This parameter is required when the `policyType` is `FulcioCAWithRekor`. The maximum length is 8192 characters.
 <9> Optional: Specifies one of the following processes to verify the identity in the signature and the actual image identity:
 * `MatchRepoDigestOrExact`.
 * `MatchRepository`.
@@ -257,5 +257,5 @@ msg="Found a Sigstore attachment manifest with 1 layers" file="docker/docker_ima
 msg="Fetching Sigstore attachment 1/1: sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45" file="docker/docker_image_src.go:644"
 # ...
 ----
-<1> The `IsRunningImageAllowed` line confirms that image is allowed by the configured sigstore verification policy. 
+<1> The `IsRunningImageAllowed` line confirms that image is allowed by the configured sigstore verification policy.
 <2> The `Using transport \"docker\" specific policy section \"example.io/crio/signed\"" file="signature/policy_eval.go:150` line confirms that the image policy has been applied.

modules/ossm-rn-new-features-1x.adoc

@@ -164,7 +164,7 @@ There are manual steps that must be completed to address CVE-2021-29492 and CVE-
 [id="manual-updates-cve-2021-29492_{context}"]
 === Manual updates required by CVE-2021-29492 and CVE-2021-31920
 
-Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (``%2F` or ``%5C`) could potentially bypass an Istio authorization policy when path-based authorization rules are used.
+Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (`%2F` or `%5C`) could potentially bypass an Istio authorization policy when path-based authorization rules are used.
 
 For example, assume an Istio cluster administrator defines an authorization DENY policy to reject the request at path `/admin`. A request sent to the URL path `//admin` will NOT be rejected by the authorization policy.
 

modules/telco-observability-key-performance-metrics.adoc

@@ -36,7 +36,7 @@ The following tables show some queries that you can explore in the metrics query
 [NOTE]
 ====
 The URL for the console is https://<OpenShift Console FQDN>/monitoring/query-browser.
-You can get the Openshift Console FQDN by running 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}'

modules/ztp-deleting-node-using-siteconfig.adoc

@@ -101,7 +101,7 @@ If you are working with secrets, deleting a secret too early can cause an issue
 Delete the secret only after the node cleanup, when the current ArgoCD synchronization is complete.
 ====
 
-.Next Steps
+.Next steps
 
 To reprovision a node, delete the changes previously added to the `SiteConfig`, push the changes to the Git repository, and wait for the synchronization to complete.
 This regenerates the `BareMetalHost` CR of the worker node and triggers the re-install of the node.

observability/logging/logging-6.0/log6x-meta-contributing.adoc

@@ -9,10 +9,10 @@ include::_attributes/common-attributes.adoc[]
 Do not include this file in the topic map. This is a guide meant for contributors, and is not intended to be published.
 ====
 
-Logging consists of the Red Hat Openshift Logging Operator (also known as the Cluster Logging Operator), and an accompanying log store Operator. Either the Loki Operator (current/future), or Elasticsearch (deprecated). Either vector (current/future) or fluentd (deprecated) handles log collection and aggregation. Operators use custom resources (CR) to manage applications and their components. High-level configuration and settings are provided by the user within a CR. The Operator translates high-level directives into low-level actions, based on best practices embedded within the Operator’s logic. A custom resource definition (CRD) defines a CR and lists all the configurations available to users of the Operator. Installing an Operator creates the CRDs, which are then used to generate CRs.
+Logging consists of the Red Hat OpenShift Logging Operator (also known as the Cluster Logging Operator), and an accompanying log store Operator. Either the Loki Operator (current/future), or Elasticsearch (deprecated). Either vector (current/future) or fluentd (deprecated) handles log collection and aggregation. Operators use custom resources (CR) to manage applications and their components. High-level configuration and settings are provided by the user within a CR. The Operator translates high-level directives into low-level actions, based on best practices embedded within the Operator’s logic. A custom resource definition (CRD) defines a CR and lists all the configurations available to users of the Operator. Installing an Operator creates the CRDs, which are then used to generate CRs.
 
 == Operator CRs:
-* `Red Hat Openshift Logging Operator`
+* `Red Hat OpenShift Logging Operator`
 ** (Deprecated) `ClusterLogging` (CL) - Deploys the collector and forwarder which currently are both implemented by a daemonset running on each node.
 ** `ClusterLogForwarder` (CLF) - Generates collector configuration to forward logs per user configuration.
 * `Loki Operator`:

scalability_and_performance/index.adoc

@@ -13,7 +13,7 @@ To contact Red Hat support, see xref:../support/getting-support.adoc#getting-sup
 
 [NOTE]
 ====
-Some performance and scalability Operators have release cycles that are independent from {product-title} release cycles. For more information, see link:access.redhat.com/support/policy/updates/openshift_operators[Openshift Operators].
+Some performance and scalability Operators have release cycles that are independent from {product-title} release cycles. For more information, see link:access.redhat.com/support/policy/updates/openshift_operators[OpenShift Operators].
 ====
 
 [discrete]
@@ -58,4 +58,4 @@ xref:../scalability_and_performance/enabling-workload-partitioning.adoc#enabling
 
 xref:../scalability_and_performance/node-observability-operator.adoc#using-node-observability-operator[Using the Node Observability Operator]
 
-// endif::[]
+// endif::[]