gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Before this update, when you used `skopeo` or a similar tool to inspect the {pipelines-title} Operator bundle, an incorrect name, `serverless-operator`, was displayed. With this update, the issue is resolved and the correct name, `openshift-pipelines-operator-rh`, is displayed.
Revised: * Before this update, using {pac} could unintentionally trigger a pipeline run when adding a label to a pull request. With this update, a `PipelineRun` is only triggered by a label if it is specifically configured to activate upon that label's addition.
Original: * Before this update, when you used `skopeo` or a similar tool to inspect the {pipelines-title} Operator bundle, an incorrect name, `serverless-operator`, was displayed. With this update, the issue is resolved and the correct name, `openshift-pipelines-operator-rh`, is displayed.
Revised: * Before this update, when using {pac}, adding a label to a pull request could unintentionally trigger a pipeline run. With this update, a `PipelineRun` resource is triggered only after you add a label to a pull request.
Original: If you are upgrading a Google Cloud Platform (GCP) or Amazon Web Services (AWS) cluster from {product-title} 4.18 to 4.19, and you have not configured the `managedBootImages` parameter, the upgrade is blocked with the _This cluster is GCP or AWS but lacks a boot image configuration._ message. The update is blocked intentionally in order to alert you that the default updated boot image behavior is changing between version 4.18 and 4.19 to enable updated boot images by default.
Revised: If you are upgrading a Google Cloud Platform (GCP) or an Amazon Web Services (AWS) cluster from {product-title} {product-version} to 4.19, and you have not configured the `managedBootImages` parameter, the upgrade is blocked and a `This cluster is GCP or AWS but lacks a boot image configuration` message is outputted. The update is blocked intentionally to alert you that the default updated boot image behavior is changing between version {product-version} and 4.19 to enable updated boot images by default.
Original: If you are updating a {GCP} or {AWS} cluster from {product-title} 4.18 to 4.19, and you have not configured the `managedBootImages` parameter, the update is blocked with a _This cluster is GCP or AWS but lacks a boot image configuration._ message. The update is blocked intentionally in order to alert you that the default updated boot image behavior is changing between version 4.18 and 4.19 to enable updated boot images by default.
Revised: If you are updating a {GCP} or {AWS} cluster from {product-title} 4.18 to 4.19, and you have not configured the `managedBootImages` parameter, the update is blocked with a _This cluster is GCP or AWS but lacks a boot image configuration._ message. The update is blocked intentionally in order to alert you that the default updated boot image behavior is changing between version 4.18 and 4.19 to enable updated boot images by default on those platforms.
Original: * Red Hat Enterprise Linux 10 is added as a certified guest operating system. For a complete list of supported guest operating systems, see link:https://access.redhat.com/articles/4234591[Certified Guest Operating Systems in OpenShift Virtualization].
Revised: * {op-system-base-full} 10 is added as a certified guest operating system. For a complete list of supported guest operating systems, see link:https://access.redhat.com/articles/4234591[Certified Guest Operating Systems in OpenShift Virtualization].
Original: The `PolicyGenerator` API is part of the link:https://open-cluster-management.io/[Open Cluster Management] standard and provides a generic way of patching resources which is not possible with the `PolicyGenTemplate` API.
Revised: The `PolicyGenerator` API is part of the link:https://open-cluster-management.io/[Open Cluster Management] standard and provides a generic way of patching resources, which is not possible with the `PolicyGenTemplate` API.
Original: Fence Agents Remediation (FAR) is generally recommended over Self Node Remediation Operator (SNRO) because it provides faster workload recovery by quickly resetting failed nodes through supported fencing agents, improving overall virtual machine high availability. For more information, see the link:https://access.redhat.com/articles/7057929[VM HA KCS] article. 
Revised: Fence Agents Remediation (FAR) is generally recommended over Self Node Remediation Operator (SNRO) because it resets failed nodes faster using supported fencing agents, which improves overall virtual machine high availability. For more information, see link:https://access.redhat.com/articles/7057929[VM HA KCS].
Original: Fence Agents Remediation (FAR) is generally recommended over Self Node Remediation Operator (SNRO) because it provides faster workload recovery by quickly resetting failed nodes through supported fencing agents, improving overall virtual machine high availability. For more information, see the link:https://access.redhat.com/articles/7057929[VM HA KCS] article. 
Revised: Fence Agents Remediation (FAR) is generally recommended over Self Node Remediation Operator (SNR) because it provides faster workload recovery by quickly resetting failed nodes through supported fencing agents, improving overall virtual machine high availability. For more information, see the link:https://access.redhat.com/articles/7057929[VM HA KCS] article.
Original: [NOTE]
====
Fence Agents Remediation (FAR) is generally recommended over Self Node Remediation Operator (SNRO) because it resets failed nodes faster using supported fencing agents, which improves overall virtual machine high availability. For more information, see link:https://access.redhat.com/articles/7057929[VM HA KCS] article. 

Revised: [NOTE]
====
Fence Agents Remediation uses supported fencing agents to reset failed nodes faster than the Self Node Remediation Operator. This improves overall virtual machine high availability. For more information, see the link:https://access.redhat.com/articles/7057929[OpenShift Virtualization - Fencing and VM High Availability Guide] knowledgebase article.
====
Original: link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/logging/index#log6x-upgrading-to-6[Upgrading to Logging 6.0]
Revised: * link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/logging/index#log6x-upgrading-to-6[Upgrading to Logging 6.0]
Original: * Currently, when the OpenShift tenancy mode is enabled, the `ServiceAccount` object of the gateway component of a `TempoStack` or `TempoMonolithic` instance requires the `TokenReview` and `SubjectAccessReview` permissions for authorization.
Revised: * Currently, when the OpenShift tenancy mode is enabled, the `ServiceAccount` object of the gateway component of either a `TempoStack` or `TempoMonolithic` instance requires the `TokenReview` and `SubjectAccessReview` permissions for authorization.
Original: * With this update, the Operator automatically upgrades all `OpenTelemetryCollector` custom resources during its startup. The Operator reconciles all managed instances during its startup: if there is an error, the Operator retries the upgrade at exponential backoff. If an upgrade fails, the Operator will retry the upgrade again when it restarts.
Revised: * With this update, the Operator automatically upgrades all `OpenTelemetryCollector` custom resources during its startup. The Operator reconciles all managed instances during its startup. If there is an error, the Operator retries the upgrade at exponential backoff. If an upgrade fails, the Operator retries the upgrade again when it restarts.
Original: In the {OTELName} 3.6, the Loki Exporter, which is a temporary Technology Preview feature, is removed. If you currently use the Loki Exporter for Loki 3.0 or later, replace the Loki Exporter with the OTLP HTTP Exporter.
Revised: In the {OTELName} 3.6, the Loki Exporter, which was a temporary Technology Preview feature, is removed. If you currently use the Loki Exporter for Loki 3.0 or later, replace the Loki Exporter with the OTLP HTTP Exporter.
Original: The {OTELOperator} automatically upgrades all `OpenTelemetryCollector` custom resources during its startup. The Operator reconciles all managed instances during its startup: if there is an error, the Operator retries the upgrade at exponential backoff. If an upgrade fails, the Operator will retry the upgrade again when it restarts.
Revised: The {OTELOperator} automatically upgrades all `OpenTelemetryCollector` custom resources during its startup. The Operator reconciles all managed instances during its startup. If there is an error, the Operator retries the upgrade at exponential backoff. If an upgrade fails, the Operator retries the upgrade again when it restarts.
Original: * You can now use a PVC as the source of a custom `DataImportCron` in the `dataImportCronTemplates` section of the `HyperConverged` custom resource (CR). See xref:../../virt/storage/virt-automatic-bootsource-updates.adoc#virt-automatic-bootsource-updates[Managing automatic boot source updates] for more information.
Revised: * You can now use a persistent volume claim (PVC) as the source of a custom `DataImportCron` in the `dataImportCronTemplates` section of the `HyperConverged` custom resource (CR). See xref:../../virt/storage/virt-automatic-bootsource-updates.adoc#virt-automatic-bootsource-updates[Managing automatic boot source updates] for more information.
Original: //[discrete]
//[id="microshift-4-19-installation-bug-fixes"]
//=== Installation
Revised: * In previous versions of {microshift-short} and {op-system-base}, {microshift-short} container image embedding procedure was advertised to use the default container storage directory, which prevented proper image updates. With this release, the recommended image embedding procedure was changed to use a dedicated directory per each image and a systemd service copying those embedded images into the default container storage.
(link:https://issues.redhat.com/browse/OCPBUGS-52420[OCPBUGS-52420])
Original: //[discrete]
//[id="microshift-4-19-installation-bug-fixes"]
//=== Installation
Revised: * Previously, the `kustomizer` sub-service was blocking `microshift.service` readiness by adding a manifest that required a webhook for a Custom Resource (CR) before {microshift-short} had started. This resulted in `kustomizer` failing, causing {microshift-short} to fail. With this release, {microshift-short} is no longer dependent on the `kustomizer` sub-service, and can start even if a manifest is malformed by `kustomizer`. (link:https://issues.redhat.com/browse/OCPBUGS-51365[OCPBUGS-51365])
Original: With this update, {pipelines-title} General Availability (GA) 1.16.4 is available on {OCP} 4.15 and later versions.
Revised: With this update, {pipelines-title} General Availability (GA) 1.16.4 is available on {OCP} 4.12, 4.14, 4.15, 4,16, 4.17 and 4.18 versions.
Original: * Before this update, the Buildah task failed with a "permission denied" error. This occurred because directories passed as volumes were assigned default `ReadWrite` permissions, while the entitlement secret was mounted as `read-only`. This mismatch caused the task to fail. With this update, the Buildah task supports the entitlement use case without encountering permission issues.
Revised: * Before this update, the Buildah task failed with a `permission denied` error. This occurred because directories passed as volumes were assigned default `ReadWrite` permissions, while the entitlement secret was mounted as `read-only`. This mismatch caused the task to fail. With this update, the Buildah task supports the entitlement use case without encountering permission issues.
Original: * Before this update, the Buildah task failed with a `permission denied` error. This occurred because directories passed as volumes were assigned default `ReadWrite` permissions, while the entitlement secret was mounted as `read-only`. This mismatch caused the task to fail. With this update, the Buildah task supports the entitlement use case without encountering permission issues.
Revised: * Before this update, when you used the `buildah` task that is supplied in the `openshift-pipelines` namespace and provided a credentials secret using the `dockerconfig` workspace, the task failed with a `permission denied` error. This failure occurred because directories passed as volumes were assigned default `ReadWrite` permissions, while the entitlement secret was mounted as `read-only`. This mismatch caused the task to fail. With this update, the `buildah` task supports the entitlement use case without encountering permission issues.
Original: * Before this update, the `git-clone` task used an outdated image that failed on disconnected clusters. With this update, a newer image for the `git-clone` task supports operation in disconnected environments.
Revised: * Before this update, the `git-clone` task that is supplied in the `openshift-pipelines` namespace used an outdated image that failed on disconnected clusters. With this update, a newer image for the `git-clone` task supports operation in disconnected environments.
Original: Administrators can now use the `ClusterUserDefinedNetwork` custom resource to deploy secondary networks on a `Localnet` topology that overlay network to your physical network. This feature provides pods and virtual machines attached to the overlay network (`Localnet` network) the ability to egress to the physical network. For more information, see xref:../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#nw-cudn-localnet[Creating a ClusterUserDefinedNetwork CR for a Localnet topology].
Revised: Administrators can now use the `ClusterUserDefinedNetwork` custom resource to deploy secondary networks on a `localnet` topology. This feature allows pods and virtual machines connected to the Localnet network to egress to the physical network. For more information, see xref:../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#nw-cudn-localnet[Creating a ClusterUserDefinedNetwork CR for a Localnet topology].
Original: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when {cmo-first} detects that Prometheus query selectors might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries could also be floats.
Revised: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when {cmo-first} detects that Prometheus query or relabel configs could be too restrictive, it takes into account that values on the `le` label of classic histograms or the `quantile` label of summaries could also be floats.
Original: * The values of the `le` label for classic histograms and the `quantile` label for summaries are normalized during ingestion. For example, the `example_bucket{le="10"}` metric selector is ingested as `example_bucket{le="10.0"}`. As a result, alerts, recording rules, dashboards, and relabeling configurations that reference label values as whole numbers, for example, `le="10"`, no longer work. 
Revised: * The values of the `le` label for classic histograms and the `quantile` label for summaries are normalized during ingestion. For example, the `example_bucket{le="10"}` metric selector is ingested as `example_bucket{le="10.0"}`. As a result, alerts, recording rules, dashboards, and relabeling configurations that reference label values as whole numbers, for example, `le="10"`, might no longer work as intended.
Original: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when {cmo-first} detects that Prometheus query selectors might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries could also be floats.
Revised: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when Prometheus queries or relabel configurations use selectors that overlook the fact that values on the `le` label of classic histograms or the `quantile` label of summaries are floats in Prometheus v3, the alert is best-effort.
Original: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when Prometheus queries or relabel configurations use selectors that could be too restrictive and might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries could also be floats. For more information, see the following "Prometheus v3 upgrade" section.
Revised: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when Prometheus queries or relabel configurations use selectors that could be too restrictive and might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries are floats in Prometheus v3. For more information, see the following "Prometheus v3 upgrade" section.
Original: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when Prometheus queries or relabel configurations use selectors that could be too restrictive and might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries are floats in Prometheus v3. For more information, see the following "Prometheus v3 upgrade" section.
Revised: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when Prometheus queries or relabel configurations use selectors that could be too restrictive and might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries are floats in Prometheus v3. For more information, see the "Prometheus v3 upgrade" section.
Original: To mitigate the issue, upgrade any affected Alertmanager instances to support the v2 API (supported since Alertmanager `v0.16.0`) and update your monitoring configuration to use the v2 scheme.
Revised: To mitigate the issue, upgrade any affected Alertmanager instances to support the v2 API, which is supported since Alertmanager `v0.16.0`, and update your monitoring configuration to use the v2 scheme.
Original: This release introduces a major update to the Prometheus component, transitioning from v2 to v3. The monitoring stack and other core components include all necessary adjustments to ensure a smooth upgrade. However, some user-managed configurations might require modifications. The key changes include the following items:
Revised: This release introduces a major update to the Prometheus component, transitioning from v2 to v3. The monitoring stack and other core components include all of the necessary adjustments to ensure a smooth upgrade. However, some user-managed configurations might require modifications. The key changes include the following items:
Original: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when Prometheus queries or relabel configurations use selectors that could be too restrictive and might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries are floats in Prometheus v3. For more information, see the "Prometheus v3 upgrade" section.
Revised: * Added the `PrometheusPossibleNarrowSelectors` alert to warn users when PromQL queries or metric relabel configurations use selectors that could be too restrictive and might not take into account that values on the `le` label of classic histograms or the `quantile` label of summaries are floats in Prometheus v3. For more information, see the "Prometheus v3 upgrade" section.
Original: * You can now xref:../../virt/managing_vms/virt-edit-vms.adoc#virt-updating-multiple-vms_virt-edit-vms[update the machine type of multiple virtual machines (VMs) at the same time] from the `oc` CLI.
Revised: * You can now xref:../../virt/managing_vms/virt-edit-vms.adoc#virt-updating-multiple-vms_virt-edit-vms[update the machine type of multiple virtual machines (VMs) at the same time] from the {oc-first}.
Original: If you plan to migrate an {aws-short} machine template that uses this feature to a Machine API compute machine set, you must set the `httpPutResponseHopLimit` and `httpTokens` fields to their default values.
Revised: If you plan to migrate an {aws-short} machine template that uses this feature to a Machine API compute machine set, you must set the `httpEndpoint`, `httpPutResponseHopLimit`, and `instanceMetadataTags` fields to their default values.
Original: * Previously, an issue started from an incorrect bucket name that was used for Red Hat Enterprise Linux CoreOS (RHCOS) . Users could not create {product-title} clusters because of a failed RHCOS image import. This problem was resolved by correcting the cluster creation in the Madrid zone for the `PowerVS` installer-provisioned infrastructure {cluster-capi-operator} by using the correct bucket name. With this release, the user can create {product-name} clusters in  the Madrid zone by using the installation program. (link:https://issues.redhat.com/browse/OCPBUGS-53142[OCPBUGS-53142])
Revised: * Previously, an issue started from an incorrect bucket name that was used for Red Hat Enterprise Linux CoreOS (RHCOS). Users could not create {product-title} clusters because of a failed RHCOS image import. This problem was resolved by correcting the cluster creation in the Madrid zone for the `PowerVS` installer-provisioned infrastructure {cluster-capi-operator} by using the correct bucket name. With this release, the user can create {product-name} clusters in  the Madrid zone by using the installation program. (link:https://issues.redhat.com/browse/OCPBUGS-53142[OCPBUGS-53142])
Original: * Previously, API server subject alternative name (SAN) validation was performed regardless of public key infrastructure (PKI) reconciliation status, causing potential connectivity issues with Hosted Control Plane clusters due to invalid SANs. With this release, a fix removes validation for {product-title} API server SANs when PKI reconciliation is disabled. The Hosted Control Plane performance is improved by eliminating unnecessary validation, especially when the PKI reconciliation is not managed. (link:https://issues.redhat.com/browse/OCPBUGS-56627[OCPBUGS-56627])
Revised: * Previously, API server subject alternative name (SAN) validation was performed regardless of public key infrastructure (PKI) reconciliation status, causing potential connectivity issues with hosted control plane clusters due to invalid SANs. With this release, a fix removes validation for {product-title} API server SANs when PKI reconciliation is disabled. The hosted control plane performance is improved by eliminating unnecessary validation, especially when the PKI reconciliation is not managed. (link:https://issues.redhat.com/browse/OCPBUGS-56627[OCPBUGS-56627])
Original: * Previously, an issue started from an incorrect bucket name that was used for {op-system-first} (RHCOS). Users could not create {product-title} clusters because of a failed {op-system} image import. This problem was resolved by correcting the cluster creation in the Madrid zone for the `PowerVS` installer-provisioned infrastructure {cluster-capi-operator} by using the correct bucket name. With this release, the user can create {product-name} clusters in  the Madrid zone by using the installation program. (link:https://issues.redhat.com/browse/OCPBUGS-53142[OCPBUGS-53142])
Revised: * Previously, an issue started from an incorrect bucket name that was used for {op-system-first}. Users could not create {product-title} clusters because of a failed {op-system} image import. This problem was resolved by correcting the cluster creation in the Madrid zone for the `PowerVS` installer-provisioned infrastructure {cluster-capi-operator} by using the correct bucket name. With this release, the user can create {product-title} clusters in  the Madrid zone by using the installation program. (link:https://issues.redhat.com/browse/OCPBUGS-53142[OCPBUGS-53142])