1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

Fixing some typos

This commit is contained in:
Andrea Hoffer
2025-02-03 14:45:50 -05:00
committed by openshift-cherrypick-robot
parent ba5656b853
commit cbf96e5d0f
8 changed files with 13 additions and 13 deletions

View File

@@ -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

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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}'

View File

@@ -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.

View File

@@ -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 Operators 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 Operators 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`:

View File

@@ -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::[]