gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, {product-title} release 4.14.52 and later releases remained on the stable-4.14 channel instead of switching to the eus-4.14 channel. This caused 'VersionNotFound' errors when attempting to retrieve update information and since the version is not found in the stable-4.14 channel, the recommended updates are not available. With this release, the installer directs 4.14.52 and later releases to the Extended Update Support (EUS) channel ensuring the releases receive recommended update notices and the `VersonNotFound` error no longer displays. (link:https://issues.redhat.com/browse/OCPBUGS-55193[OCPBUGS-55193])
Revised: * Previously, {product-title} release 4.14.52 and later releases remained on the stable-4.14 channel instead of switching to the eus-4.14 channel. This caused 'VersionNotFound' errors when attempting to retrieve update information. Because the version was not found in the stable-4.14 channel, the recommended updates were not available. With this release, the installer directs 4.14.52 and later releases to the Extended Update Support (EUS) channel, ensuring the releases receives the recommended update notices, and the `VersonNotFound` error no longer displays. (link:https://issues.redhat.com/browse/OCPBUGS-55193[OCPBUGS-55193])
Original: * Previously, cluster nodes repeatedly lose communication due to improper remote port binding by Open Virtual Network (OVN)-Kubernetes. This affects pod communication across nodes. With this release, the remote port binding functionality has been updated to be handled by OVN directly, improving the reliability of cluster node communication. (link:https://issues.redhat.com/browse/OCPBUGS-48522[OCPBUGS-48522])
Revised: * Previously, cluster nodes repeatedly lost communication due to improper remote port binding by Open Virtual Network (OVN)-Kubernetes. This affected pod communication across nodes. With this release, the remote port binding functionality has been updated to be handled by OVN directly, improving the reliability of cluster node communication. (link:https://issues.redhat.com/browse/OCPBUGS-48522[OCPBUGS-48522])
Original: * Previously, when installing a cluster on {ibm-cloud-name} into an existing Virtual Private Cloud (VPC), the installation program retrieved an unsupported VPC region. Attempting to install into a supported VPC region that follows the unsupported VPC region alphabetically caused the installation program to crash. With this release, the installation program ignores any VPC regions that are not fully available during resource lookups. (link:https://issues.redhat.com/browse/OCPBUGS-48196[OCPBUGS-48196])
Revised: * Previously, when you installed a cluster on {ibm-cloud-name} into an existing Virtual Private Cloud (VPC), the installation program retrieved an unsupported VPC region. If you tried to install into a supported VPC region that followed the unsupported VPC region alphabetically, the installation program crashed. With this release, the installation program ignores any VPC regions that are not fully available during resource lookups. (link:https://issues.redhat.com/browse/OCPBUGS-48196[OCPBUGS-48196])
Original: * Previously, an operator would incorrectly appear twice in the installed operators list if the current project matched its default namespace and the copied CSVs were disabled in {olm-first}. With this release, the operator displays only once. (link:https://issues.redhat.com/browse/OCPBUGS-55942[OCPBUGS-55942])
Revised: * Previously, an operator would incorrectly appear twice in the installed operators list if the current project matched its default namespace and the copied CSVs were disabled in {olmv1-first}. With this release, the operator displays only once. (link:https://issues.redhat.com/browse/OCPBUGS-55942[OCPBUGS-55942])
Original: |This parameter is only for compute machines. `bootDiagnostics` contains the value for the storage account of the Uniform Resource Identifier (URI) that receives the machine log information for the compute machines. `type` specifies the {azure-short} boot diagnostics type for the created compute machines. When you set `type` to `UserManaged`, you must provide the values for `resourceGroup` and `storageAccountName`. When you set `type` to `Managed`, the installation program provides the values for these parameters. When you set `type` to `Disabled`, you turn off the parameter.
Revised: |This parameter enables boot diagnostics collection for compute machines. `type` specifies the {azure-short} boot diagnostics type for the created compute machines. When you set `type` to `UserManaged`, you must provide the values for `resourceGroup` and `storageAccountName`. When you set `type` to `Managed`, the installation program provides the values for these parameters. When you set `type` to `Disabled`, you turn off the parameter.
Original: |This parameter enables boot diagnostics collection for compute machines. `type` specifies the {azure-short} boot diagnostics type for the created compute machines. When you set `type` to `UserManaged`, you must provide the values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and  {product-title} cluster nodes, ensure that you use the same region and subscription. When you set `type` to `Managed`, {azure-short} stores the data blobs for the boot diagnostics in a managed storage account. When you set `type` to `Disabled`, you turn off the parameter.
Revised: |Enables boot diagnostics collection for compute machines. The `type` field specifies the {azure-short} boot diagnostics type for the created compute machines. When you set `type` to `UserManaged`, you must provide values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and  {product-title} cluster nodes, use the same region and subscription. When you set `type` to `Managed`, {azure-short} stores the boot diagnostics data blobs in a managed storage account. When you set `type` to `Disabled`, you turn off the parameter.
Original: |This parameter enables boot diagnostics collection for control plane machines. `type` specifies the {azure-short} boot diagnostics type for the created control plane machines. When you set `type` to `UserManaged`, you must provide the values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and {product-title} cluster nodes, ensure that you use the same region and subscription. When you set `type` to `Managed`, {azure-short} stores the data blobs for the boot diagnostics in a managed storage account. When you set `type` to `Disabled`, you turn off the parameter.
Revised: |Enables boot diagnostics collection for control plane machines. The `type` field specifies the {azure-short} boot diagnostics type for the created control plane machines. When you set `type` to `UserManaged`, you must provide values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and {product-title} cluster nodes, use the same region and subscription. When you set `type` to `Managed`, {azure-short} stores the boot diagnostics data blobs in a managed storage account. When you set `type` to `Disabled`, you turn off the parameter.
Original:     defaultMachinePlatform:
Revised: |Enables boot diagnostics collection for all machines. The `type` field specifies the {azure-short} boot diagnostics type for all the created machines. When you set `type` to `UserManaged`, you must provide values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and {product-title} cluster nodes, use the same region and subscription. When you set `type` to `Managed`, {azure-short} stores the boot diagnostics data blobs in a managed storage account. When you set `type` to `Disabled`, you turn off the parameter.
Original: |This parameter enables boot diagnostics collection for compute machines. `type` specifies the {azure-short} boot diagnostics type for the created compute machines. When you set `type` to `UserManaged`, you must provide the values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and  {product-title} cluster nodes, ensure that you use the same region and subscription. When you set `type` to `Managed`, {azure-short} stores the data blobs for the boot diagnostics in a managed storage account. When you set `type` to `Disabled`, you turn off the parameter.
Revised: a|Enables boot diagnostics collection for compute machines.  The `type` field specifies the {azure-short} boot diagnostics type for the created compute machines.

The following values are associated with the boot diagnostics type:

`Usermanaged`:: When you set `type` to `UserManaged`, you must provide values for `resourceGroup` and `storageAccountName`. For `storageAccountName` and  {product-title} cluster nodes, use the same region and subscription.
`Managed`:: When you set `type` to `Managed`, {azure-short} stores the data blobs for the boot diagnostics in a managed storage account.
`Disabled`:: When you set `type` to `Disabled`, you turn off the parameter.
Original: Red{nbsp}Hat will provide bug fixes and support for versions of the Operator SDK that were released with earlier versions of {product-title} according to the link:https://access.redhat.com/product-life-cycles?product=OpenShift%20Container%20Platform%204[Product Life Cycles for {product-title} 4] (Red{nbsp} Customer Portal).
Revised: Red{nbsp}Hat will provide bug fixes and support for versions of the Operator SDK that were released with earlier versions of {product-title} according to the link:https://access.redhat.com/product-life-cycles?product=OpenShift%20Container%20Platform%204[Product Life Cycles for {product-title} 4] (Red{nbsp}Hat Customer Portal).
Original: {product-title} 4.19 now includes a _Tutorials_ guide, which takes the place of the _Getting started_ guide in previous releases. The existing tutorials were refreshed and the guide now focuses solely on hands-on tutorial content. It also provides a jumping off point to other recommended hands-on learning resources for {product-title} across Red Hat.
Revised: {product-title} 4.19 now includes a _Tutorials_ guide, which takes the place of the _Getting started_ guide in previous releases. The existing tutorials were refreshed and the guide now focuses solely on hands-on tutorial content. It also provides a jumping off point to other recommended hands-on learning resources for {product-title} across Red{nbsp}Hat.
Original: ==== Creating a route with externally managed certificate (General Availability)
Revised: With this release, {product-title} routes can be configured with third-party certificate management solutions by using the `.spec.tls.externalCertificate` field in the route API. This allows you to reference externally managed TLS certificates through secrets, streamlining the process by eliminating manual certificate management. By using externally managed certificates, you reduce errors, ensure a smoother certificate update process, and enable the OpenShift router to promptly serve renewed certificates. For more information, see xref:../networking/routes/secured-routes.adoc#nw-ingress-route-secret-load-external-cert_secured-routes[Creating a route with externally managed certificate].
Original: * For information on installing Intel Gaudi Base Operator on OpenShift, see link:https://docs.habana.ai/en/latest/Installation_Guide/Additional_Installation/OpenShift_Installation/index.html[OpenShift Installation].
Revised: * link:https://docs.habana.ai/en/latest/Installation_Guide/Additional_Installation/OpenShift_Installation/index.html[OpenShift Installation].
Original: 
* A working OpenShift cluster with at least one GPU worker node.

* Access to the OpenShift cluster as a cluster-admin to perform the required steps.

* OpenShift CLI (oc) is installed.

* The Node Feature Discovery (NFD) Operator is installed and a NodeFeatureDiscovery instance is created. 
Revised: 
* You have a working OpenShift cluster with at least one GPU worker node.

* You have access to the OpenShift cluster as a cluster-admin to perform the required steps.

* You have installed OpenShift CLI (oc).

* You have installed the Node Feature Discovery (NFD) Operator and created a NodeFeatureDiscovery instance.
Original: 
* A working OpenShift cluster with at least one GPU worker node.

* Access to the OpenShift cluster as a cluster-admin to perform the required steps.

* OpenShift CLI (oc) is installed.

* The Node Feature Discovery (NFD) Operator is installed and a NodeFeatureDiscovery instance is created. 
Revised: 
* A working {product-title} cluster with at least one GPU worker node.

* Access to the {product-title} cluster as a cluster-admin to perform the required steps.

* {oc-first} is installed.

* The Node Feature Discovery (NFD) Operator is installed and a NodeFeatureDiscovery instance is created.
Original: * link:https://docs.habana.ai/en/latest/Installation_Guide/Additional_Installation/OpenShift_Installation/index.html[OpenShift Installation].

* link:https://docs.redhat.com/en/documentation/red_hat_openshift_ai_self-managed/2.20/html/working_with_accelerators/intel-gaudi-ai-accelerator-integration_accelerators#intel-gaudi-ai-accelerator-integration_accelerators[Intel Gaudi AI Accelerator integration].
Revised: * link:https://docs.habana.ai/en/latest/Installation_Guide/Additional_Installation/OpenShift_Installation/index.html[OpenShift Installation] (Intel Gaudi documentation)

* link:https://docs.redhat.com/en/documentation/red_hat_openshift_ai_self-managed/2.20/html/working_with_accelerators/intel-gaudi-ai-accelerator-integration_accelerators#intel-gaudi-ai-accelerator-integration_accelerators[Intel Gaudi AI Accelerator integration]
Original: include::_attributes/attributes-openshift-dedicated.adoc[]
:namespace: openshift-adp
:local-product: OADP
:must-gather-v1-3: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
:must-gather-v1-4: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
You can collect logs, metrics, and information about {local-product} custom resources by using the `must-gather` tool. The `must-gather` data must be attached to all customer cases.
You can run the `must-gather` tool with the following data collection options:
Revised: The `must-gather` tool is a container and does not run all the time. The tool runs for a few minutes only after a user invokes the tool by running the `must-gather` command.
Original: include::_attributes/attributes-openshift-dedicated.adoc[]
:namespace: openshift-adp
:local-product: OADP
:must-gather-v1-3: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
:must-gather-v1-4: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
You can collect logs, metrics, and information about {local-product} custom resources by using the `must-gather` tool. The `must-gather` data must be attached to all customer cases.
Revised: You can collect logs and information about {oadp-short} custom resources by using the `must-gather` tool. The `must-gather` data must be attached to all customer cases.
Original: include::_attributes/attributes-openshift-dedicated.adoc[]
:namespace: openshift-adp
:local-product: OADP
:must-gather-v1-3: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
:must-gather-v1-4: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
You can collect logs, metrics, and information about {local-product} custom resources by using the `must-gather` tool. The `must-gather` data must be attached to all customer cases.
You can run the `must-gather` tool with the following data collection options:

* Full `must-gather` data collection collects Prometheus metrics, pod logs, and Velero CR information for all namespaces where the OADP Operator is installed.
* Essential `must-gather` data collection collects pod logs and Velero CR information for a specific duration of time, for example, one hour or 24 hours. Prometheus metrics and duplicate logs are not included.
* `must-gather` data collection with timeout. Data collection can take a long time if there are many failed `Backup` CRs. You can improve performance by setting a timeout value.
* Prometheus metrics data dump downloads an archive file containing the metrics data collected by Prometheus.


.Prerequisites

* You have logged in to the {product-title} cluster as a user with the `cluster-admin` role.
* You have installed the OpenShift CLI (`oc`).
* You must use {op-system-base-full} {op-system-version-9} with {oadp-short} 1.4.

.Procedure

. Navigate to the directory where you want to store the `must-gather` data.
. Run the `oc adm must-gather` command for one of the following data collection options:

* For full `must-gather` data collection, including Prometheus metrics, run the following command:
+
[source,terminal,subs="attributes+"]
----
$ oc adm must-gather --image={must-gather-v1-4}
----
+
The data is saved as `must-gather/must-gather.tar.gz`. You can upload this file to a support case on the link:https://access.redhat.com/[Red{nbsp}Hat Customer Portal].
+
For essential `must-gather` data collection, without Prometheus metrics, for a specific time duration, run the following command:
+
[source,terminal,subs="attributes+"]
----
$ oc adm must-gather --image={must-gather-v1-4} \
-- /usr/bin/gather_<time>_essential <1>
----
<1> Specify the time in hours. Allowed values are `1h`, `6h`, `24h`, `72h`, or `all`, for example, `gather_1h_essential` or `gather_all_essential`.

* For `must-gather` data collection with timeout, run the following command:
+
[source,terminal,subs="attributes+"]
----
$ oc adm must-gather --image={must-gather-v1-4} \
-- /usr/bin/gather_with_timeout <timeout> <1>
----
<1> Specify a timeout value in seconds.

* For a Prometheus metrics data dump, run the following command:
+
[source,terminal,subs="attributes+"]
----
$ oc adm must-gather --image={must-gather-v1-4} -- /usr/bin/gather_metrics_dump
----
This operation can take a long time. The data is saved as `must-gather/metrics/prom_data.tar.gz`.
Revised: The `must-gather` tool is a container and does not run all the time. The tool runs for a few minutes only after you invoke the tool by running the `must-gather` command.
Original: Default configuration:: This configuration collects pod logs, {oadp-short} and `Velero` custom resource (CR) information for all namespaces where the {oadp-short} Operator is installed.
Revised: Default configuration:: This configuration collects pod logs, {oadp-short}, and `Velero` custom resource (CR) information for all namespaces where the {oadp-short} Operator is installed.
Original: The SPIFFE Container Storage Interface (CSI) is a plugin that helps pods securely obtain their {svid-full} by delivering the Workload API socket into the pod. The SPIFFE CSI driver is deployed as a daemonset on the cluster ensuring that a driver instance runs on each node. The driver uses the ephemeral inline volume capability of Kubernetes allowing pods to request volumes directly provided by the SPIFFE CSI driver simplifying their use by applications that need temporary storage.
Revised: The SPIFFE Container Storage Interface (CSI) is a plugin that helps pods securely obtain their {svid-full} by delivering the Workload API socket into the pod. The SPIFFE CSI driver is deployed as a daemonset on the cluster ensuring that a driver instance runs on each node. The driver uses the ephemeral inline volume capability of Kubernetes allowing pods to request volumes directly provided by the SPIFFE CSI driver. this simplifies volume use by applications that need temporary storage.
Original: SPIRE OpenId Connect Federation (OIDC) capability allows workloads to authenticate to external systems using short-lived OIDC credentials. An OIDC Discovery Provider servers as a trusted source for OIDC documents, enabling other OIDC providers to validate tokens issued by SPIRE. These documents contain all the essential URLs, supported features, and configuration details allowing the client applications to be dynamically configured to work with other OIDC Providers.
Revised: The SPIRE OIDC Discovery Provider is a standalone component that makes SPIRE-issued JWT-SVIDs compatible with standard OpenID Connect (OIDC) consumers by exposing a .well-known/openid-configuration endpoint and a JWKS URI for token verification. It is essential for integrating SPIRE-based workload identity with systems that require OIDC-compliant tokens, especially, external APIs. While SPIRE primarily issues identities for workloads, additional workload-related claims can be embedded into JWT-SVIDs through SPIRE's configuration, allowing these claims to be included in the token and verified by OIDC-compliant clients.
Original: The SPIRE Controller Manager uses custom resource definitions (CRDs) to facilitate the registration of workloads and establish federation relationships. To facilitate workload registration, the SPIRE Controller Manager registers controllers against pods and CRDs. When changes are detected on these resources, a workload reconciliation process is triggered. This process determines which SPIRE entries should exist based on the existing pods and CRDs. The reconciliation process creates, updates, and deletes entries on the SPIRE server as appropriate.
Revised: The SPIRE Controller Manager uses custom resource definitions (CRDs) to facilitate the registration of workloads. To facilitate workload registration, the SPIRE Controller Manager registers controllers against pods and CRDs. When changes are detected on these resources, a workload reconciliation process is triggered. This process determines which SPIRE entries should exist based on the existing pods and CRDs. The reconciliation process creates, updates, and deletes entries on the SPIRE server as appropriate.
Original: SPIRE server and agent telemetry provide insight into the health of the SPIRE deployment. The metrics are in the format provided by the Prometheus Operator. The following are some of the metrics that can be displayed by the SPIRE server:

* monitoring

* debugging

* performance analysis

* alerting

The SPIRE agent telemetry refers to the metrics and logs provided by the SPIRE agent. The following are some of the metrics available in the SPIRE agent:

* agent startup time

* node attestation

* workload attestation

* SVID requests and issuance
Revised: SPIRE server and agent telemetry provide insight into the health of the SPIRE deployment. The metrics are in the format provided by the Prometheus Operator. The metrics exposed help in understanding server health & lifecycle, spire component performance, attestation and SVID issuance and plugin statistics.
Original: For more information, see link:https://azure.microsoft.com/en-us/updates?id=default-outbound-access-for-vms-in-azure-will-be-retired-updates-and-more-information[Azure Updates], link:https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections#scenarios[Azure's outbound connectivity methods], and User-provisioned infrastructure.
Revised: For more information, see link:https://azure.microsoft.com/en-us/updates?id=default-outbound-access-for-vms-in-azure-will-be-retired-updates-and-more-information[Azure Updates] (Microsoft documentation), link:https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections#scenarios[Azure's outbound connectivity methods] (Microsoft documentation), and User-provisioned infrastructure.
Original: With this release, you can enable user-provisioned DNS instead of the default cluster-provisioned DNS solution. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. In such scenarios, you can use your own DNS service to bypass the public DNS service. You can manage your DNS only for the IP addresses of the API and Ingress servers. If you use this feature, you must provide your own DNS solution that includes records for `api.<cluster_name>.<base_domain>.` and `*.apps.<cluster_name>.<base_domain>.`.
Revised: With this release, you can enable user-provisioned DNS instead of the default cluster-provisioned DNS solution. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. You can manage your DNS only for the IP addresses of the API and Ingress servers. If you use this feature, you must provide your own DNS solution that includes records for `api.<cluster_name>.<base_domain>.` and `*.apps.<cluster_name>.<base_domain>.`.