gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, when re-running oc-mirror plugin v2 with the same working directory, existing `tar` archive files from previous runs were not removed. This resulted in a mix of outdated and new archives, which could cause mirroring failures when pushing to the target registry.
Revised: * Previously, when re-running oc-mirror plugin v2 with the same working directory, existing `tar` archive files from previous runs were not removed. This resulted in a mix of outdated and new archives, which could cause mirroring failures when pushing to the target registry. With this update, oc-mirror plugin v2 automatically deletes old `tar` archive files at the beginning of each run, ensuring that the working directory only contains archives from the current execution. (link:https://issues.redhat.com/browse/OCPBUGS-56433[OCPBUGS-56433])
Original: * Previously, oc-mirror v2 would terminate with an error if the source registry responded with an HTTP 502, 503, or 504 status code during image copying.
Revised: * Previously, oc-mirror plugin v2 would terminate with an error if the source registry responded with any of the following HTTP status codes during image copying: 502, 503, 504. With this update, oc-mirror plugin v2 automatically retries the copy operation when encountering these temporary server errors. (link:https://issues.redhat.com/browse/OCPBUGS-56185[OCPBUGS-56185])
Original: With this update, oc-mirror plugin v2 supports Helm charts that reference images using both tag and digest. The tool mirrors the image using the digest as the source and applies the tag at the destination.
Revised: With this update, oc-mirror plugin v2 supports Helm charts that reference images using both tag and digest. The tool mirrors the image using the digest as the source and applies the tag at the destination. (link:https://issues.redhat.com/browse/OCPBUGS-54891[OCPBUGS-54891])
Original: [id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
Revised: * Previously, image import blocked registries that would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
Original: [id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
* Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
Revised: * Previously, the installation program did not prevent users from attempting to install a single-node cluster on bare metal, which resulted in a failed installation. With this update, the installation program prevents single-node cluster installations on unsupported platforms. (link:https://issues.redhat.com/browse/OCPBUGS-56811[OCPBUGS-56811])
Original: [id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
* Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
Revised: * Previously, when you diagnosed issues related to running the `openshift-install destroy cluster` command for {vmw-first}, the logging information provided insufficient detail. As a consequence, it was unclear why clusters were not removed from virtual machines (VMs). With this release, when you destroy a cluster, enhanced debug logging is provided and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-56372[OCPBUGS-56372])
Original: [id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
* Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
Revised: * Previously, when installing a cluster with the `OVNKubernetes` network plugin, the installation could fail if the plugin is specified as `OVNkubernetes` with a lowercase "k". With this update, the installation program correctly interprets the plugin name regardless of case. (link:https://issues.redhat.com/browse/OCPBUGS-54606[OCPBUGS-54606])
Original: [id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
* Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
Revised: * Previously, when installing a cluster on {aws-short} in the `us-east-1` regions, the installation could fail if no zone is specified in the `install-config.yaml` file because the `use1-az3` zone does not support any instance types supported by {product-title}. With this update, the installation program prevents the use of the `use1-az3` zone when no zones are specified in the installation configuration file. (link:https://issues.redhat.com/browse/OCPBUGS-47477[OCPBUGS-47477])
Original: There was an error in detecting whether storage live migration was enabled or not. link:https://issues.redhat.com/browse/MIG-1746[(MIG-1746)]
Revised: In MTC, there is an error when detecting whether storage live migration is enabled. This issue is resolved in MTC 1.8.8 link:https://issues.redhat.com/browse/MIG-1746[(MIG-1746)]
Original: apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/name: "agent"
    app.kubernetes.io/instance: "spire"
    name: spire-agent
  namespace: zero-trust-workload-identity-manager
spec:
  endpoints:
  - interval: 30s
    port: metrics
    path: /metrics
selector:
    matchLabels:
      app.kubernetes.io/name: "agent"
      app.kubernetes.io/instance: "spire"
    namespaceSelector:
    matchNames:
    - zero-trust-workload-identity-manager
Revised: apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
app.kubernetes.io/name: agent
app.kubernetes.io/instance: spire
name: spire-agent-metrics
namespace: zero-trust-workload-identity-manager
spec:
endpoints:
interval: 30s
path: /metrics
selector:
matchLabels:
app.kubernetes.io/name: agent
app.kubernetes.io/instance: spire
namespaceSelector:
matchNames:
Original: apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/name: "server"
    app.kubernetes.io/instance: "spire"
    name: spire-server
  namespace: zero-trust-workload-identity-manager
spec:
  endpoints:
  - interval: 30s
    port: metrics
    path: /metrics
selector:
    matchLabels:
      app.kubernetes.io/name: "server"
      app.kubernetes.io/instance: "spire"
    namespaceSelector:
    matchNames:
    - zero-trust-workload-identity-manager
Revised: apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
app.kubernetes.io/name: server
app.kubernetes.io/instance: spire
name: spire-server-metrics
namespace: zero-trust-workload-identity-manager
spec:
endpoints:
interval: 30s
path: /metrics
selector:
matchLabels:
app.kubernetes.io/name: server
app.kubernetes.io/instance: spire
namespaceSelector:
matchNames:
Original: The SPIRE Agent operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Agent by creating a `ServiceMonitor` custom resource, which enables Prometheus Operator to scrape custom metrics.
Revised: The SPIRE Agent operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Agent by creating a `ServiceMonitor` custom resource (CR), which enables Prometheus Operator to scrape custom metrics.
Original: As a cluster administrator, or as a user with view access to all namespaces, you can query SPIRE Agent and Server metrics using the {product-title} web console or the command line. The query retrieves all the metrics collected from the SPIRE components that match the specified job labels.
Revised: As a cluster administrator, or as a user with view access to all namespaces, you can query SPIRE Agent and SPIRE Server metrics by using the {product-title} web console or the command line. The query retrieves all the metrics collected from the SPIRE components that match the specified job labels.
Original: The SPIRE Server operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Server by creating a `ServiceMonitor` Custom Resource (CR) that enables Prometheus Operator to collect custom metrics.
Revised: The SPIRE Server operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Server by creating a `ServiceMonitor` custom resource (CR) that enables Prometheus Operator to collect custom metrics.
Original: . In the query field, enter the following `expression` to query SPIRE Server metrics:
+
[source,terminal]
----
$ {job="spire-server"}
----

. In the query field, enter the following `expression` to query SPIRE Agent metrics.
+
[source,terminal]
----
Revised: . In the query field, enter the following PromQL expression to query SPIRE Server metrics:

[source,promql]
{job="spire-server"}

. In the query field, enter the following PromQL expression to query SPIRE Agent metrics.

[source,promql]
{job="spire-agent"}
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, ensuring node stability. (link:https://issues.redhat.com/browse/OCPBUGS-45272[OCPBUGS-45272])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the Kubernetes NMState Operator Operator did not create the `nmstate-console-plugin` pod because of an issue with the `pluginPort` template. With this release, a fix to the template ensures that the Operator can now succesfully create the `nmstate-console-plugin` pod. (link:https://issues.redhat.com/browse/OCPBUGS-54295[OCPBUGS-54295])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the DNS-based egress firewall incorrectly prevented creation of any firewall rule that contained a DNS name in uppercase characters. With this release, a fix to the egress firewall means that creation of a firewall rule that contains a DNS name in uppercase characters occurs. (link:https://issues.redhat.com/browse/OCPBUGS-46564[OCPBUGS-46564])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the HAProxy router incorrectly assumed that only SHA1 leaf certificates were rejected by HAProxy, causing the router to fail by not rejecting SHA1 intermediate certificates. With this update, the router now inspects and rejects all non-self-signed SHA1 certificates, thereby preventing crashes and improving cluster stability. (link:https://issues.redhat.com/browse/OCPBUGS-45290[OCPBUGS-45290])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, HAProxy left idle connections open when it reloaded its configuration until either the next time a client sent a request by using the idle connection or the `hard-stop-after` period elapsed. This release adds a new `IdleConnectionTerminationPolicy` API field to control HAProxy behavior for idle connections during reloads. The new default setting is `Immediate`, which means that HAProxy immediately terminates any idle connections when it reloads its configuration. The previous behavior can be specified by using the `Deferred` setting for `IdleConnectionTerminationPolicy`. (link:https://issues.redhat.com/browse/OCPBUGS-43745[OCPBUGS-43745])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the pod controller in the Whereabouts reconciler was not passing the namespace to the leader election function, so the pod controller was not deleting orphaned allocations. This lead to repeated log error messages. With this release, the namespace is passed in and the orphaned allocations are deleted properly. (link:https://issues.redhat.com/browse/OCPBUGS-53397[OCPBUGS-53397])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the `SriovOperatorConfig` Operator removed any parameters that had default values in the `SriovOperatorConfig` resources. This situation caused certain information to be missing from the output of a resource. With this release, the Operator uses the PATCH method for API servers to preserve parameters with default values so that no information is missing from the output for a resource. (link:https://issues.redhat.com/browse/OCPBUGS-53346[OCPBUGS-53346])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, a cluster with the `clusterNetwork` parameter listing multiple networks of the same IP address family entered a `crashloopbackoff` state when upgrading to the latest version of {product-title}. With this release,  a fix ensures that the cluster with this configuration no longer enters the `crashloopbackoff` state during a cluster upgrade. (link:https://issues.redhat.com/browse/OCPBUGS-49994[OCPBUGS-49994])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the `resolv-prepender` service triggered earlier than expected. This situation caused the service to fail and resulted in an incorrectly configured setting for the host DNS. With this release, the configuration for the `resolv-prepender` service is updated so that when the service triggers earlier than expected, it no longer causes incorrect configuration of the host DNS settings. (link:https://issues.redhat.com/browse/OCPBUGS-49436[OCPBUGS-49436])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, the `nmstate-configuration` service was only enabled for deployments that had the `platform` parameter set to `baremetal`. However, you could also use the Assisted Installer to configure a bare-metal deployment by setting the `platform` parameter set to  `None`,  but the NMState `br-ex` network bridge creation feature did not work with this installation method.  With this release, the `nmstate-configuration` service is moved to the base directory in the cluster installation path so that any deployments configured with the `platform` parameter set to  `None`, do not impact the NMState `br-ex` network bridge creation feature. (link:https://issues.redhat.com/browse/OCPBUGS-48566[OCPBUGS-48566])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, for a layer 2 or layer 3 topology network that had the gateway mode set to `local`, OVN-Kubernetes experienced an issue when it was restarted. The issue caused the Egress IP to be selected as the primary IP address for the network. With this release, a fix ensures that this behavior no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-46585[OCPBUGS-46585])
Original: * Before this update, when a pod used the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might have been unexpectedly deleted. As a consequence, when the pod's DHCP lease expired, the DHCP proxy entered a loop when trying to re-create a new lease, leading to the node becoming unresponsive. With this release, the DHCP lease maintenance terminates if the network interface does not exist. As a result, interface deletions are handled gracefully, which ensures node stability.(link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*])
Revised: * Previously, when a pod was running on a node on which an egress on the IPv6 protocol was assigned, the pod was not able to communicate with the OVN-Kubernetes service in a dual-stack cluster. This resulted in the traffic with the IP address family, that the `egressIP` was not applicable to, being dropped. With this release, only the source network address translation (SNAT) for the IP address family that the egress IPs applied to is deleted, eliminating the risk of traffic being dropped. (link:https://issues.redhat.com/browse/OCPBUGS-46543[OCPBUGS-46543])