gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: The `HTTPRoute` resource must have the `Gateway` object's name as the value for its `parentRefs` field in order to attach to the gateway. Implicitly, the route is assumed to be in the same namespace as the `Gateway` object.
Revised: The `HTTPRoute` resource must have the name of the `Gateway` object as the value for its `parentRefs` field in order to attach to the gateway. Implicitly, the route is assumed to be in the same namespace as the `Gateway` object.
Original: An example of a `Gateway` resource, `devops-gateway`, that has a label selector `spec.listeners.allowedRoutes.namespaces` set to match any namespaces containing `shared-gateway-access: "true"`:
Revised: The following example shows a `Gateway` resource, `devops-gateway`, that has a `spec.listeners.allowedRoutes.namespaces` label selector set to match any namespaces containing `shared-gateway-access: "true"`:
Original: With a shared gateway topology, the routes must specify the namespace of the `Gateway` object it wants to attach to. Multiple `Gateway` objects can be deployed and shared across namespaces. When there are multiple shared gateways this becomes conceptually similar to Ingress Controller sharding.
Revised: With a shared gateway topology, the routes must specify the namespace of the `Gateway` object it wants to attach to. Multiple `Gateway` objects can be deployed and shared across namespaces. When there are multiple shared gateways, this becomes conceptually similar to Ingress Controller sharding.
Original: Use the {external-secrets-operator} to integrate link:https://external-secrets.io/latest/[External Secrets Operator] with the {product-title} cluster. The `external-secrets` application fetches secrets stored in the external providers such as link:https://aws.amazon.com/secrets-manager/[AWS Secrets Manager], link:https://developer.hashicorp.com/vault[HashiCorp Vault], link:https://cloud.google.com/security/products/secret-manager[Google Secrets Manager], link:https://azure.microsoft.com/en-us/products/key-vault/[Azure Key Vault], link:https://www.ibm.com/products/secrets-manager[{ibm-cloud-title} Secrets Manager] and integrates them with Kubernetes in a secure and automated manner.
Revised: Use the {external-secrets-operator} to integrate link:https://external-secrets.io/latest/[external-secrets] with the {product-title} cluster. The `external-secrets` application fetches secrets stored in the external providers such as link:https://aws.amazon.com/secrets-manager/[AWS Secrets Manager], link:https://developer.hashicorp.com/vault[HashiCorp Vault], link:https://cloud.google.com/security/products/secret-manager[Google Secrets Manager], link:https://azure.microsoft.com/en-us/products/key-vault/[Azure Key Vault], link:https://www.ibm.com/products/secrets-manager[{ibm-cloud-title} Secrets Manager] and integrates them with Kubernetes in a secure and automated manner.
Original: Use the {external-secrets-operator} to integrate link:https://external-secrets.io/latest/[external-secrets] with the {product-title} cluster. The `external-secrets` application fetches secrets stored in the external providers such as link:https://aws.amazon.com/secrets-manager/[AWS Secrets Manager], link:https://developer.hashicorp.com/vault[HashiCorp Vault], link:https://cloud.google.com/security/products/secret-manager[Google Secrets Manager], link:https://azure.microsoft.com/en-us/products/key-vault/[Azure Key Vault], link:https://www.ibm.com/products/secrets-manager[{ibm-cloud-title} Secrets Manager], link:https://external-secrets.io/latest/provider/aws-parameter-store/[AWS Parameter Store] and integrates them with Kubernetes in a secure and automated manner.
Revised: Use the {external-secrets-operator} to integrate link:https://external-secrets.io/latest/[external-secrets] with the {product-title} cluster. The `external-secrets` Operator fetches secrets stored by external providers such as link:https://aws.amazon.com/secrets-manager/[AWS Secrets Manager], link:https://developer.hashicorp.com/vault[HashiCorp Vault], link:https://cloud.google.com/security/products/secret-manager[Google Secrets Manager], link:https://azure.microsoft.com/en-us/products/key-vault/[Azure Key Vault], link:https://www.ibm.com/products/secrets-manager[{ibm-cloud-title} Secrets Manager], link:https://external-secrets.io/latest/provider/aws-parameter-store/[AWS Parameter Store] and integrates them with Kubernetes in a secure and automated manner.
Original: ----
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-k8s
  namespace: external-secrets-operator
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: prometheus-k8s
  namespace: external-secrets-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: prometheus-k8s
subjects:
- kind: ServiceAccount
  name: prometheus-k8s
  namespace: external-secrets-operator
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: external-secrets
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: external-secrets
    app.kubernetes.io/name: external-secrets
  name: external-secrets
  namespace: external-secrets-operator
spec:
  endpoints:
  - interval: 30s
    port: tcp-prometheus-servicemonitor
    scheme: http
  selector:
    matchLabels:
      app.kubernetes.io/component: controller
      app.kubernetes.io/instance: external-secrets
      app.kubernetes.io/name: external-secrets
----

. Create the `Role`, `RoleBinding`, and `ServiceMonitor` objects by running the following command:

+
[source,terminal]
Revised: apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus-k8s
namespace: external-secrets-operator
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus-k8s
namespace: external-secrets-operator
rules:
resources:
verbs:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: prometheus-k8s
namespace: external-secrets-operator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: prometheus-k8s
subjects:
name: prometheus-k8s
namespace: external-secrets-operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
app: external-secrets
app.kubernetes.io/component: controller
app.kubernetes.io/instance: external-secrets
app.kubernetes.io/name: external-secrets
name: external-secrets
namespace: external-secrets-operator
spec:
endpoints:
port: tcp-prometheus-servicemonitor
scheme: http
selector:
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: external-secrets
app.kubernetes.io/name: external-secrets
Original: You can improve storage performance by configuring multiple IOThreads for a virtual machine (VM) that uses fast storage, such as SSD or NVMe. This option is only available by editing the VM YAML.
Revised: You can improve storage performance by configuring multiple IOThreads for a virtual machine (VM) that uses fast storage, such as solid-state drive (SSD) or non-volatile memory express (NVMe). This configuration option is only available by editing YAML of the VM.
Original: Multiple IOThreads are supported only when `blockMultiQueue` is enabled and the disk bus is set to `virtio`. Disks must use `bus: virtio`, and enabling `blockMultiQueue: true` is required for this feature to work correctly.
Revised: Multiple IOThreads are supported only when `blockMultiQueue` is enabled and the disk bus is set to `virtio`. You must set this configuration for the configuration to work correctly.
Original: ifdef::openshift-rosa-hcp[]
* link:https://docs.openshift.com/rosa/cli_reference/rosa_cli/rosa-manage-objects-cli.html#rosa-edit-machinepool_rosa-managing-objects-cli[ROSA CLI reference: `rosa edit machinepool`]
endif::openshift-rosa-hcp[]
Revised: * xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-node-lifecycle_rosa-hcp-service-definition[Node lifecycle]
Original: ifdef::openshift-rosa-hcp[]
* link:https://docs.openshift.com/rosa/cli_reference/rosa_cli/rosa-manage-objects-cli.html#rosa-edit-machinepool_rosa-managing-objects-cli[ROSA CLI reference: `rosa edit machinepool`]
endif::openshift-rosa-hcp[]
Revised: * xref:../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-node-lifecycle_rosa-service-definition[Node lifecycle]
Original: xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-node-lifecycle_rosa-hcp-service-definition[Service Definition for Node lifecycle.]
Revised: xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-node-lifecycle_rosa-hcp-service-definition[Node lifecycle].
Original: The network flow matrixes describe ingress traffic flows for a base {product-title} or {sno} installation. It does not describe network flows for additional components, such as optional Operators available from the Red Hat Marketplace. The matrixes do not apply for {hcp}, Red{nbsp}Hat build of MicroShift, or standalone clusters.
Revised: The network flow matrixes describe ingress traffic flows for a base {product-title} or {sno} installation. The matrixes do not apply for {hcp}, Red{nbsp}Hat build of MicroShift, or standalone clusters.
Original: If you do not set one, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
Revised: If you do not specify a secret, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
Original: |`clientTLS` authenticates client access to the cluster and services; as a result, mutual TLS authentication is enabled. If you do not set one, then client TLS is not enabled. `clientTLS` has the required subfields, `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA`.
Revised: |`clientTLS` authenticates client access to the cluster and services; as a result, mutual TLS authentication is enabled. If you do not set a value, the client TLS is not enabled. The `clientTLS` parameter has the required subfields, `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA`.
Original: The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. Note that the ingress controller only checks client certificates for edge-terminated and reencrypt TLS routes; it cannot check certificates for cleartext HTTP or passthrough TLS routes. The `ClientCA` subfield specifies a config map that is in the openshift-ingress namespace. The config map should contain a CA certificate bundle. A config map is required for this field.
Revised: The `ClientCertificatePolicy` subfield accepts one of the following two values: `Required` or `Optional`. Note that the ingress controller only checks client certificates for edge-terminated and reencrypt TLS routes; the ingress controller cannot check certificates for cleartext HTTP or passthrough TLS routes. The `ClientCA` subfield specifies a config map that is in the `openshift-ingress` namespace. The config map should contain a CA certificate bundle. A config map is required for this field.
Original: |The port range allowed for Kubernetes services of type `NodePort`. If not specified, the default range of 30000-32767 is used. Services without a `NodePort` specified are automatically allocated one from this range. This parameter can be updated after {microshift-short} starts.
Revised: |The port range allowed for Kubernetes services of type `NodePort`. If you do not specify the range, the default range of `30000-32767` is used. Services without a `NodePort` specified are automatically allocated one from this range. This parameter can be updated after {microshift-short} starts.
Original: If you do not set one, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
Revised: If you do not set one of these values, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
Original: |`ingress.routeAdmissionPolicy.namespaceOwnership`
|Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Specifying `Strict` prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized {microshift-short} `config.yaml`, the `InterNamespaceAllowed` value is automatically set.
Revised: |Specifies settings for ingress controllers TLS connections. If you do not set one, the default value is based on the `apiservers.config.openshift.io/cluster` resource.
Original: |`ingress.routeAdmissionPolicy.namespaceOwnership`
|Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Specifying `Strict` prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized {microshift-short} `config.yaml`, the `InterNamespaceAllowed` value is automatically set.
Revised: |`Old`, `Intermediate`, `Modern`, `Custom`
Original: |`ingress.routeAdmissionPolicy.namespaceOwnership`
|Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Specifying `Strict` prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized {microshift-short} `config.yaml`, the `InterNamespaceAllowed` value is automatically set.
Revised: When using the `Old`, `Intermediate`, and `Modern` profile types, the effective profile configuration is subject to change between releases. For example, given a specification to use the `Intermediate` profile deployed on release `X.Y.Z`, an upgrade to release `X.Y.Z+1` might cause a new profile configuration to be applied to the ingress controller, resulting in a rollout.
Original: |Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Specifying `Strict` prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized {microshift-short} `config.yaml`, the `InterNamespaceAllowed` value is automatically set.
Revised: |Describes how hostname claims across namespaces should be handled. The default value is `Strict`. Specifying `Strict` prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized {microshift-short} `config.yaml` file, the `InterNamespaceAllowed` value is automatically set.
Original: |Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Specifying `Strict` prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized {microshift-short} `config.yaml`, the `InterNamespaceAllowed` value is automatically set.
Revised: * `Strict`: does not allow routes to claim the same hostname across namespaces. +
* `next_entry`:
* `Strict`: does not allow routes to claim the same hostname across namespaces. +

* `next_entry`:
Original: In order to prevent the custom layered images from taking up excessive space in your registry, you can automatically remove an on-cluster custom layered image from the repository by deleting the `MachineOSBuild` object that created the image. 
Revised: To prevent the custom layered images from taking up excessive space in your registry, you can automatically remove an on-cluster custom layered image from the repository by deleting the `MachineOSBuild` object that created the image.
Original: The credentials provided by the registry push secret that you added to the the `MachineOSBuild` object must grant permission to delete an image from the registry. If the delete permission is not present, the image is not removed when you delete the `MachineOSBuild` object.
Revised: The credentials provided by the registry push secret that you added to the `MachineOSBuild` object must grant the permission for deleting an image from the registry. If the delete permission is not provided, the image is not removed when you delete the `MachineOSBuild` object.
Original: A network policy applies to only the TCP, UDP, ICMP, and SCTP protocols. Other protocols are not affected.
Network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
Revised: * A network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
* Network policies do not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
Original: A network policy applies to only the TCP, UDP, ICMP, and SCTP protocols. Other protocols are not affected.
Network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
Revised: * A Network policy object using the `spec.ingress.from.namespaceSelector` field without the `spec.podSelector` field set to `{}` will not include `hostNetwork` pods. You must use the `podSelector` set to `{}` with the `namespaceSelector` field in order to target `hostNetwork` pods when creating network policies.
Original: * Previously, `observability-operator` and `perses-operator` pods entered a `CrashLoopBackOff` state due to `OutOfMemory` errors, after upgrading from {coo-full} 1.0. This release resolves the issue. (link:https://issues.redhat.com/browse/COO-784[*COO-784*])
Revised: * Previously, `observability-operator` and `perses-operator` pods entered a `CrashLoopBackOff` state on many clusters due to `OutOfMemory` errors, after upgrading from {coo-full} 1.0. This release resolves the issue for most cluster configurations.  (link:https://issues.redhat.com/browse/COO-784[*COO-784*])
Original: <1> The OpenAPI File Path is `<project_application_dir>/specs/stock-portfolio-svc.yaml`. The generated key that configures the URL for the REST client is `stock_portfolio_svc_yaml`
Revised: <1> The OpenAPI file path is `<project_application_dir>/specs/stock-portfolio-svc.yaml`. The generated key that configures the URL for the REST client is `stock_portfolio_svc_yaml`.
Original: The wait period in each validation is five minutes by default. After the wait period, if the validation has not succeeded, it is declared a failure. This wait period is incrementally increased by the base wait period after each boot in the verification loop.
* You can override the base-time wait period by setting the `MICROSHIFT_WAIT_TIMEOUT_SEC` environment variable in the `/etc/greenboot/greenboot.conf` configuration file. For example, you can change the wait time to three minutes by resetting the value to 180 seconds, such as `MICROSHIFT_WAIT_TIMEOUT_SEC=180`.
Revised: * You can override the base-time wait period by setting the `MICROSHIFT_WAIT_TIMEOUT_SEC` environment variable in the `/etc/greenboot/greenboot.conf` configuration file. For example, you can change the wait time to five minutes by resetting the value to 300 seconds, such as `MICROSHIFT_WAIT_TIMEOUT_SEC=300`.
Original: 2. The {op-system-base} KVM host in your environment must meet certain requirements to host the virtual machines that you plan for the {product-title} environment. See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_virtualization/getting-started-with-virtualization-in-rhel-8_configuring-and-managing-virtualization[Getting started with virtualization].
Revised: For detailed system requirements, see link:https://www.ibm.com/support/pages/linux-ibm-zibm-linuxone-tested-platforms[Linux on {ibm-z-name}/{ibm-linuxone-name} tested platforms] (IBM Support).
Original: In the {product-title}, the route API is extended to provide a configurable option to reference TLS certificates via secrets. With the xref:../../networking/routes/secured-routes.adoc#nw-ingress-route-secret-load-external-cert_secured-routes[Creating a route with externally managed certificate] Technology Preview feature enabled, you can minimize errors from manual intervention, streamline the certificate management process, and enable the {product-title} router to promptly serve the referenced certificate.
Revised: In the {product-title}, the route API is extended to provide a configurable option to reference TLS certificates via secrets. With the xref:../../networking/routes/secured-routes.adoc#nw-ingress-route-secret-load-external-cert_secured-routes[Creating a route with externally managed certificate] feature enabled, you can minimize errors from manual intervention, streamline the certificate management process, and enable the {product-title} router to promptly serve the referenced certificate.
Original: In the {product-title}, the route API is extended to provide a configurable option to reference TLS certificates via secrets. With the xref:../../networking/routes/secured-routes.adoc#nw-ingress-route-secret-load-external-cert_secured-routes[Creating a route with externally managed certificate] Technology Preview feature enabled, you can minimize errors from manual intervention, streamline the certificate management process, and enable the {product-title} router to promptly serve the referenced certificate.

:FeatureName: Securing routes with the {cert-manager-operator}
include::snippets/technology-preview.adoc[]
Revised: In the {product-title}, the route API is extended to provide a configurable option to reference TLS certificates via secrets. With xref:../../networking/routes/secured-routes.adoc#nw-ingress-route-secret-load-external-cert_secured-routes[externally managed certificates] enabled, you can minimize errors from manual intervention, streamline the certificate management process, and enable the {product-title} router to promptly serve the referenced certificate.
Original: An empty `status` section in a storage profile indicates that a storage provisioner is not recognized by the Containerized Data Interface (CDI). Customizing a storage profile is necessary if you have a storage provisioner that is not recognized by CDI. In this case, the administrator sets appropriate values in the storage profile to ensure successful allocations.
Revised: An empty `status` section in a storage profile indicates that a storage provisioner is not recognized by the Containerized Data Importer (CDI). Customizing a storage profile is necessary if you have a storage provisioner that is not recognized by CDI. In this case, the administrator sets appropriate values in the storage profile to ensure successful allocations.