gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: {ols-official} generates answers to questions based on the content in the official {ocp-product-title} product documentation. The documentation for the following products is not part of the {ocp-short-name} product documentation; therefore, {ols-short} has limited context for generating answers about these products:
Revised: The {ocp-product-title} product documentation does not include information about all products in the {red-hat} portfolio. As a result, the {ols-official} service uses the large language model (LLM) you provide to produce output for the following products or components:
Original: = Preparing to install on Nutanix
Before you install an {product-title} cluster, be sure that your Nutanix environment meets the following requirements.
Revised: You can install an {product-title} cluster on Nutanix by using a variety of different installation methods. Each method has qualities that can make the method more suitable for different use cases, such as installing a cluster in a disconnected environment or installing a cluster that requires minimal configuration and provisioning. Before you install {product-title}, ensure that your Nutanix environment meets specific requirements.
Original: = Preparing to install on Nutanix
Before you install an {product-title} cluster, be sure that your Nutanix environment meets the following requirements.
Revised: For example, the Agent-based Installer can be used to install a three-node cluster, which is a smaller, more resource-efficient cluster for testing, development, and production. See xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#preparing-to-install-with-agent-based-installer[Preparing to install with the Agent-based Installer] for additional details.
Original: The {ols-long} service uses a large language model (LLM) to generate responses to questions. The BYO Knowledge tool can be used to create a retrieval-augmented generation (RAG) database to enhance the knowledge that is available to the LLM. When you create a RAG database you customize the {ols-long} service for your environment. For example, a network administrator can develop a standard operating procedure (SOP) that is used to provision an {ocp-product-title} cluster. Then, the network administrator can use the BYO Knowledge tool to enhance the knowledge available to the LLM by including information from the SOP.
Revised: The {ols-long} service uses a large language model (LLM) to generate responses to questions. You can enhance the knowledge that is available to the LLM by using the BYO Knowledge tool to create a retrieval-augmented generation (RAG) database.

When you create a RAG database, you customize the {ols-long} service for your environment. For example, a network administrator can develop a standard operating procedure (SOP) that is used to provision an {ocp-product-title} cluster. Then, the network administrator can use the BYO Knowledge tool to enhance the knowledge available to the LLM by including information from the SOP.
Original: * You are logged in to the {ocp-product-title} web console as a user with the `cluster-admin` role. Alternatively, you are logged in to a user account that has permission to create a cluster-scoped CR file.
Revised: * You are logged in to the {ocp-product-title} web console as a user account that has permission to create a cluster-scoped custom resource (CR) file.
* You are logged in to the {ocp-product-title} web console as a user account that has permission to create a cluster-scoped custom resource (CR) file, such as a user with the `cluster-admin` role.
Original: . Refresh the page when a pop-up message instructs you to do so. 
. Navigate to the Observe → Logs panel where you can run LogQL queries. You can aslo query Logs for individual pods from the pods view *Aggregated Logs* tab.
Revised: . Refresh the page when a pop-up message instructs you to do so.
. Navigate to the Observe → Logs panel where you can run LogQL queries. You can also query Logs for individual pods from the pods view *Aggregated Logs* tab.
Original: * Verify the installation by running the following command:
+
[source,terminal]
----
$ oc get pods -n openshift-logging
----
+
.Example output
[source,terminal]
----
$ oc get pods -n openshift-logging
NAME                                               READY   STATUS    RESTARTS   AGE
cluster-logging-operator-56764d8c76-7m9kg          1/1     Running   0          19m
logging-loki-compactor-0                           1/1     Running   0          10m
logging-loki-distributor-657647b49b-2hxwl          1/1     Running   0          10m
logging-loki-distributor-657647b49b-qdnpf          1/1     Running   0          10m
logging-loki-gateway-79c497c9-69mqs                2/2     Running   0          10m
logging-loki-gateway-79c497c9-hd9w5                2/2     Running   0          10m
logging-loki-index-gateway-0                       1/1     Running   0          10m
logging-loki-index-gateway-1                       1/1     Running   0          10m
logging-loki-ingester-0                            1/1     Running   0          10m
logging-loki-ingester-1                            1/1     Running   0         9m38s
logging-loki-querier-59c966d69c-ggjlg              1/1     Running   0          10m
logging-loki-querier-59c966d69c-n6c2g              1/1     Running   0          10m
logging-loki-query-frontend-bc86757-8qzwd          1/1     Running   0          10m
logging-loki-query-frontend-bc86757-kswxk          1/1     Running   0          10m
logging-loki-ruler-0                               1/1     Running   0          10m
logging-loki-ruler-1                               1/1     Running   0          10m

----

Revised: . Access the OpenShift Container Platform web console and refresh the page if a pop-up message instructs you to do so.
. Navigate to the Observe → Logs panel where you can run LogQL queries. You can also query Logs for individual pods from the pods view *Aggregated Logs* tab.
Original: . Install the {coo-full}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/cluster_observability_operator/installing-cluster-observability-operators[Cluster Observability Operator].
Revised: . Install the {coo-full}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/cluster_observability_operator/installing-cluster-observability-operators[Installing the Cluster Observability Operator].
Original: Keep the following in mind when you create a pod that is given a QoS class of `Guaranteed`:
* Every container in the pod must have a memory limit and a memory request, and they must be the same.
* Every container in the pod must have a CPU limit and a CPU request, and they must be the same.
The following example shows the configuration file for a pod that has one container. The container has a memory limit and a memory request, both equal to 200 MiB. The container has a CPU limit and a CPU request, both equal to 1 CPU.
Revised: * Access to the cluster as a user with the `cluster-admin` role
Original: Keep the following in mind when you create a pod that is given a QoS class of `Guaranteed`:
* Every container in the pod must have a memory limit and a memory request, and they must be the same.
* Every container in the pod must have a CPU limit and a CPU request, and they must be the same.
The following example shows the configuration file for a pod that has one container. The container has a memory limit and a memory request, both equal to 200 MiB. The container has a CPU limit and a CPU request, both equal to 1 CPU.
Revised: * The OpenShift CLI (`oc`)
Original: Keep the following in mind when you create a pod that is given a QoS class of `Guaranteed`:
* Every container in the pod must have a memory limit and a memory request, and they must be the same.
* Every container in the pod must have a CPU limit and a CPU request, and they must be the same.
The following example shows the configuration file for a pod that has one container. The container has a memory limit and a memory request, both equal to 200 MiB. The container has a CPU limit and a CPU request, both equal to 1 CPU.
Revised: .. Create a YAML file that defines the `Pod` resource:
Original: name: openai-api-keys
url: <URL> <1>
<1> The URL endpoint must end with `v1` to be valid. For example, `\https://http://3.23.103.8:8000/v1`.
Revised: <1> By default, the {rhelai} API key requires a token as part of the request. If your {rhelai} configuration does not require a token, you must set the token value to any valid string for the request to authenticate.
Original: name: openai-api-keys
url: <url> <1>
<1> The URL endpoint must end with `v1` to be valid. For example, `\https://<model_name>.<domain_name>.com:443/v1`.
Revised: <1> By default, the {rhoai} API key requires a token as part of the request. If your {rhoai} configuration does not require a token, you must set the token value to any valid string for the request to authenticate.
Original: From {product-title} {product-version}, Cloud Credential Operator pods deploy with the `readOnlyRootFilesystem` security context setting set to `true`. This enhances security by ensuring that the container root file system is mounted as read-only. 
Revised: With this release, Cloud Credential Operator pods now deploy with the `readOnlyRootFilesystem` security context setting set to `true`. This enhances security by ensuring that the container root file system is mounted as read-only.
Original: {ServerlessProductName} 1.34.1 is now available. This release of {ServerlessProductName} addresses identified Common Vulnerabilities and Exposures (CVEs) to enhance security and reliability. Fixed issues and known issues that pertain to {ServerlessProductName} on {ocp-product-title} are included in the following notes:
Revised: {ServerlessProductName} 1.35.1 is now available. This release of {ServerlessProductName} addresses identified Common Vulnerabilities and Exposures (CVEs) to enhance security and reliability. Fixed issues and known issues that pertain to {ServerlessProductName} on {ocp-product-title} are included in the following notes:
Original: * In some scenarios, cluster-scoped resources such as webhook configurations may remain after uninstalling, reinstalling, or upgrading KnativeServing or the {ServerlessOperatorName}. These leftover resources can block the reconciliation process and prevent KnativeServing from installing properly.When this issue occurs, you may see an error similar to the following:
Revised: * In some scenarios, cluster-scoped resources such as webhook configurations may remain after uninstalling, reinstalling, or upgrading KnativeServing or the {ServerlessOperatorName}. These leftover resources can block the reconciliation process and prevent KnativeServing from installing properly. When this issue occurs, you may see an error similar to the following:
Original: * Previously, the `sinks.knative.dev` API group was missing from the KnativeEventing aggregate cluster roles. As a result, non-admin users encountered the following error when running `oc get all` command:
Revised: * Previously, the `sinks.knative.dev` API group was missing from the KnativeEventing aggregate cluster roles. As a result, non-admin users encountered the following error when running the `oc get all` command:
Original: * In some scenarios, cluster-scoped resources such as webhook configurations may remain after uninstalling, reinstalling, or upgrading KnativeServing or the {ServerlessOperatorName}. These leftover resources can block the reconciliation process and prevent KnativeServing from installing properly. When this issue occurs, you may see an error similar to the following:
Revised: * In some scenarios, cluster-scoped resources, such as webhook configurations, might remain after uninstalling, reinstalling, or upgrading KnativeServing or the {ServerlessOperatorName}. These leftover resources can block the reconciliation process and prevent KnativeServing from installing properly. When this issue occurs, you might see an error similar to the following:
Original: * Previously, the `kafka-controller-post-install-1.35` job failed after installing `KnativeKafka` if the `KafkaChannel` feature was not enabled. This issue has been fixed. The post-install job now completes successfully, even when `KafkaChannels` are disabled.
Revised: * Previously, the `kafka-controller-post-install-1.35` job failed after installing `KnativeKafka` if the `KafkaChannel` feature was not enabled. This issue has been fixed. The post-install job now completes successfully, even when the `KafkaChannels` are disabled.
Original: * Previously, the `sinks.knative.dev` API group was missing from the KnativeEventing aggregate cluster roles. As a result, non-admin users encountered the following error when running the `oc get all` command:
Revised: * Previously, the `sinks.knative.dev` API group was missing from the KnativeEventing aggregate cluster roles. As a result, if you are a non-admin user the `oc get all` command failed with the following error message:
Original: This issue has been resolved. The `sinks.knative.dev` API group is now included in the `knative-eventing-namespaced` aggregate cluster roles. Users with `view`, `edit`, or `admin` roles can now read and list sinks in their own namespaces.
Revised: This issue has been resolved. The `sinks.knative.dev` API group is now included in the `knative-eventing-namespaced` aggregate cluster roles. You can now read and list sinks in your own namespaces if you have a `view`, `edit`, or `admin` role.
Original: * In some scenarios, cluster-scoped resources such as webhook configurations, might remain after uninstalling, reinstalling, or upgrading KnativeServing or the {ServerlessOperatorName}. These leftover resources can block the reconciliation process and prevent KnativeServing from installing properly. When this issue occurs, you might see an error similar to the following:
Revised: * Currently, you cannot delete the cluster-scoped resources such as webhook configurations, that might remain after uninstalling, reinstalling, or upgrading KnativeServing or the {ServerlessOperatorName}. These leftover resources can block the reconciliation process and prevent KnativeServing from installing properly. When this issue occurs, you might see an error similar to the following:
Original: ** Configuring a local arbiter node. Enables users to configure an {product-title} cluster with two control plane nodes and one local arbiter node to retain high availability (HA) while reducing infrastructure costs. This configuration is supported only for bare-metal installations.
Revised: ** Configuring a local arbiter node. You can configure an {product-title} cluster with two control plane nodes and one local arbiter node so to retain high availability (HA) while reducing infrastructure costs for your cluster. This configuration is supported only for bare-metal installations.
Original: A local arbiter node is a lower-cost, co-located machine that participates in control plane quorum decisions. Unlike a standard control plane node, the arbiter node does not run the full set of control plane services. This setup allows you to maintain HA in your cluster with only two fully provisioned control plane nodes instead of three.
Revised: A local arbiter node is a lower-cost, co-located machine that participates in control plane quorum decisions. Unlike a standard control plane node, the arbiter node does not run the full set of control plane services. You can use this configuration to maintain HA in your cluster with only two fully provisioned control plane nodes instead of three.
Original: The update strategy affects how the update process is performed. The `spec.updateStrategy` field in the `{istio}` resource configuration determines how the Operator updates the {istio} control plane. When the Operator detects a change in the `spec.version` field or identifies a new minor release with a configured `vX.Y-latest` alias, it initiates an upgrade procedure. For each mesh, you select one of two strategies:
Revised: The update strategy affects how the update process is performed. The `spec.updateStrategy` field in the `{istio}` resource configuration determines how the OpenShift Service Mesh Operator updates the {istio} control plane. When the Operator detects a change in the `spec.version` field or identifies a new minor release with a configured `vX.Y-latest` alias, it initiates an upgrade procedure. For each mesh, you select one of two strategies:
Original: After updating the operator, update the {istio} control plane to the latest supported version. The `{istio}` resource configuration determines how the control plane upgrade is performed, including which steps require manual action and which are handled automatically.
Revised: After updating the OpenShift Service Mesh Operator , update the {istio} control plane to the latest supported version. The `{istio}` resource configuration determines how the control plane upgrade is performed, including which steps require manual action and which are handled automatically.
Original: To enable automatic patch upgrades, set the approval strategy of the Operator to `Automatic`. When the Operator detects a new patch release and the `version` field uses the `vX.Y-latest` alias, the control plane is updated based on the configured `updateStrategy`.
Revised: To enable automatic patch upgrades, set the approval strategy of the Operator to `Automatic`. When the Operator detects a new patch release and the `version` field uses the `vX.Y-latest` alias, the control plane is updated based on the configured `updateStrategy` type.
Original: :context: ossm-about-revisionbased-strategy
An update that is performed using  the `RevisionBased` strategy runs two revisions of a control plane. This capability allows you to gradually migrate workloads from the old control plane to the new control plane, making canary upgrades possible. The `RevisionBased` strategy also allows you to update by more than one minor version.
Revised: The `RevisionBased` strategy creates a new {istio} control plane instance for each change to the `spec.version` field. The existing control plane remains active until all workloads transition to the new instance. Transition workloads work by updating the `istio.io/rev` labels or using the `IstioRevisionTag` resource, followed by a restart.
Original: You can configure the {istio} control plane and workloads for the `InPlace` update strategy. When using the `InPlace` strategy, the `IstioRevision` resource created by the Operator always uses the same name as the `{istio}` resource. 
Revised: You can configure the {istio} control plane and workloads for the `InPlace` update strategy. When using the `InPlace` strategy, the `IstioRevision` resource created by the Service Mesh Operator always uses the same name as the `{istio}` resource.
Original: . Alternatively, apply the revision label to individual workloads by modifying the pod template in the `Deployment` resource.
Revised: . Attach the workloads to a control plane deployed using the InPlace strategy:

.. Labeling the namespace to automatically include all workloads by entering the following command:

[source,terminal]
$ oc label namespace <namespace_name> istio.io/rev=<revision_name>

..  Apply the revision label to individual workloads by modifying the pod template in the `Deployment` resource. For example:

[source,yaml, subs="attributes,verbatim"]
apiVersion: apps/v1
kind: Deployment
spec:
template:
metadata:
labels:
istio.io/rev: <revision_name>
Original: :context: ossm-about-inplace-strategy
The `InPlace` strategy runs only one revision of the control plane at all times. When you perform an `InPlace` update, all of the workloads immediately connect to the new version of the control plane. In order to ensure compatibility between the sidecars and the control plane you cannot upgrade by more than one minor version at a time.
Revised: While the `InPlace` strategy offers simplicity and efficiency, you might experience application traffic interruption if a workload pod updates, restarts, or scales while the control plane is restarting. You can mitigate this risk by running multiple replicas of the {istio} control plane (istiod).
Original: In this example, a linked Knowledge Base article (link:https://access.redhat.com/articles/7031404[Preparing to upgrade to {product-title} 4.16]) provides more detail about verifying API compatibility between releases.
Revised: In this example, a linked Red{nbsp}Hat Knowledgebase article (link:https://access.redhat.com/articles/7031404[Preparing to upgrade to {product-title} 4.16]) provides more detail about verifying API compatibility between releases.
Original: ** xref:../edge_computing/ztp-deploying-far-edge-sites.adoc#ztp-deploying-far-edge-sites[Installing managed clusters with {rh-acm} and SiteConfig resources]
Revised: ** xref:../edge_computing/ztp-deploying-far-edge-sites.adoc#ztp-deploying-far-edge-sites[Installing managed clusters with {rh-rhacm} and SiteConfig resources]
Original: Red Hat Advanced Cluster Management provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters. You can manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
Revised: {rh-rhacm-first} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters. You can manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
Original: The resource requirements for the hub cluster are directly dependent on the number of clusters being managed by the hub, the number of policies used for each managed cluster, and the set of features that are configured in {rh-rhacm}.
Revised: The resource requirements for the hub cluster are directly dependent on the number of clusters being managed by the hub, the number of policies used for each managed cluster, and the set of features that are configured in {rh-rhacm-first}.
Original: Red Hat Advanced Cluster Management provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters. You can manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
Revised: {rh-rhacm-first}provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters. You can manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
Original: * {cgu-operator} supports optional pre-caching of OpenShift, OLM Operator, and additional images to {sno} clusters before initiating an upgrade. The pre-caching feature is not applicable when using the recommended image-based upgrade method for upgrading {sno} clusters.
Revised: * {cgu-operator} supports optional pre-caching of OpenShift, {olm-first} Operator, and additional images to {sno} clusters before initiating an upgrade. The pre-caching feature is not applicable when using the recommended image-based upgrade method for upgrading {sno} clusters.
Original: The telco management hub reference design specifications (RDS) and the associated reference CRs describe the telco engineering and QE validated method for deploying, configuring and managing the lifecycle of telco managed cluster infrastructure.
Revised: The telco management hub reference design specifications (RDS) and the associated reference custom resources (CRs) describe the telco engineering and QE validated method for deploying, configuring and managing the lifecycle of telco managed cluster infrastructure.