gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, the `openshift-cnv` namespace components did not feature the `openshift.io/required-scc` annotation. Workloads were not requesting their required security content constraints (SCCs). Wih this release, the `openshift.io/required-scc` annotation is added to the `openshift-cnv` namespace components so that workloads can request the required SCCs. (link:https://issues.redhat.com/browse/OCPBUGS-49657[OCPBUGS-49657])
Revised: * Previously, the `openshift-cnv` namespace components did not feature the `openshift.io/required-scc` annotation. Workloads were not requesting their required security content constraints (SCCs). With this release, the `openshift.io/required-scc` annotation is added to the `openshift-cnv` namespace components so that workloads can request the required SCCs. (link:https://issues.redhat.com/browse/OCPBUGS-49657[OCPBUGS-49657])
Original: [discrete]
[id="ocp-release-note-insights-operator-bug-fixes_{context}"]
==== Insights Operator
[discrete]
[id="ocp-release-note-kube-controller-bug-fixes_{context}"]
==== Kubernetes Controller Manager
[discrete]
[id="ocp-release-note-kube-scheduler-bug-fixes_{context}"]
==== Kubernetes Scheduler
Revised: * Previously, in some slower PrismCentral environments, the installation program would fail with a timeout when make the prism-api call to load the {op-system} image. The timeout value was previously 5 minutes. With this release, the prism-api call timeout value is a configurable parameter in the `install-config.yaml` file as `platform.nutanix.prismAPICallTimeout`, with a default value of 10 minutes. (link:https://issues.redhat.com/browse/OCPBUGS-48570[OCPBUGS-48570])
Original: [discrete]
[id="ocp-release-note-oc-cli-bug-fixes_{context}"]
==== OpenShift CLI (oc)

* Previously, if you tried to add a node to a disconnected environment using the `oc adm node-image` command, private registry images were inaccessible to the command, causing node addition failure. This error only occurred if the cluster was initially installed with an installer binary downloaded from (link:https://mirror.openshift.com/pub/)[mirror.openshift.com]. With this release, a fix has been implemented that enables successful image pull and node creation in disconnected environments. (link:https://issues.redhat.com/browse/OCPBUGS-53106[OCPBUGS-53106])

* Previously, a bug on `oc adm inspect --all-namespaces` command construction meant that must-gather was not correctly gathering information about leases, `csistoragecapacities`, and the assisted-installer namespace. With this release, the issue is fixed and must-gather will gather the information correctly. (link:https://issues.redhat.com/browse/OCPBUGS-44857[OCPBUGS-44857])

* Previously, the `oc adm node-image create --pxe generated` command did not create only the Preboot Execution Environment (PXE) artifacts. Instead, the command created the PXE artifacts with other artifacts from a `node-joiner` pod and stored them all in the wrong subdirectory. Additionally, the PXE artifacts were incorrectly prefixed with `agent` instead of `node`. With this release, generated PXE artifacts are stored in the correct directory and receive the correct prefix. (link:https://issues.redhat.com/browse/OCPBUGS-45311[OCPBUGS-45311])

Revised: With this update, a progress bar has been added to provide the cache population status, enabling the user to see the current progress of the cache population. (link:https://issues.redhat.com/browse/OCPBUGS-56563[OCPBUGS-56563])
Original: * Previously, Internet Small Computer System Interface (iSCSI) and Fibre Channel devices that were attached to a multipath device did not resolve correctly when these devices were partitioned. With this relase, a fix ensures that partitioned multipath storage devices can now correctly resolve. (link:https://issues.redhat.com/browse/OCPBUGS-46038[OCPBUGS-46038])
Revised: * Previously, Internet Small Computer System Interface (iSCSI) and Fibre Channel devices that were attached to a multipath device did not resolve correctly when these devices were partitioned. With this release, a fix ensures that partitioned multipath storage devices can now correctly resolve. (link:https://issues.redhat.com/browse/OCPBUGS-46038[OCPBUGS-46038])
Original: * Previously, contents of the `MachineConfig` and `ControllerConfig` resources from group `machineconfiguration.openshift.io` were not excluded from audit logs. With this release, they are excluded from audit logs because they might contain secrets. (link:https://issues.redhat.com/browse/OCPBUGS-55709[OCPBUGS-55709])
* Previously, the kube-apiserver service level objective (SLO) alert expression incorrectly summed read and write success ratios independently of total request volume. This led to misleading burn rate calculations during disruptions. With this release, the fix adjusts the calculation to properly weight success ratios by total request count. This results in accurate and reliable alerting based on the true proportion of successful requests. (link:https://issues.redhat.com/browse/OCPBUGS-49764[OCPBUGS-49764])
Revised: * Previously, the `kube-apiserver` service level objective (SLO) alert expression incorrectly summed read and write success ratios independently of total request volume. This led to misleading burn rate calculations during disruptions. With this release, the fix adjusts the calculation to properly weight success ratios by total request count. This results in accurate and reliable alerting based on the true proportion of successful requests. (link:https://issues.redhat.com/browse/OCPBUGS-49764[OCPBUGS-49764])
Original: * Previously, contents of the `MachineConfig` and `ControllerConfig` resources from group `machineconfiguration.openshift.io` were not excluded from audit logs. With this release, they are excluded from audit logs because they might contain secrets. (link:https://issues.redhat.com/browse/OCPBUGS-55709[OCPBUGS-55709])
* Previously, the kube-apiserver service level objective (SLO) alert expression incorrectly summed read and write success ratios independently of total request volume. This led to misleading burn rate calculations during disruptions. With this release, the fix adjusts the calculation to properly weight success ratios by total request count. This results in accurate and reliable alerting based on the true proportion of successful requests. (link:https://issues.redhat.com/browse/OCPBUGS-49764[OCPBUGS-49764])
* Previously, cluster bootstrap removal could break kube-apiserver readiness if etcd access was lost which could lead to downtime. With this release, each kube-apiserver has 2 stable etcd endpoints before removing bootstrap which maintains availability during rollout. (link:https://issues.redhat.com/browse/OCPBUGS-48673[OCPBUGS-48673])
Revised: * Previously, cluster bootstrap removal could break `kube-apiserver` readiness if etcd access was lost which could lead to downtime. With this release, each `kube-apiserver` service has 2 stable etcd endpoints before removing bootstrap which maintains availability during rollout. (link:https://issues.redhat.com/browse/OCPBUGS-48673[OCPBUGS-48673])
Original: [discrete]
[id="ocp-release-note-insights-operator-bug-fixes_{context}"]
==== Insights Operator
[discrete]
[id="ocp-release-note-kube-controller-bug-fixes_{context}"]
==== Kubernetes Controller Manager
[discrete]
[id="ocp-release-note-kube-scheduler-bug-fixes_{context}"]
==== Kubernetes Scheduler
Revised: * Previously, in some slower Prism Central environments, the installation program would fail with a timeout when make the `prism-api` call to load the {op-system} image. The timeout value was previously 5 minutes. With this release, the `prism-api` call timeout value is a configurable parameter in the `install-config.yaml` file as `platform.nutanix.prismAPICallTimeout`, with a default value of 10 minutes. (link:https://issues.redhat.com/browse/OCPBUGS-48570[OCPBUGS-48570])
Original: * Previously, when you created a virtual machine (VM) and no IP addresses existed in the IP pool, the VM did not start. An error message was generated in the `virt-launcher-<vm-name>` pod, but the message was unclear as to the source of the issue. With this release, for this situation where no IP addresses exist in the IP pool, the `virt-launcher-<vm-name>` pod includes a clear error message that is similar to the following example:
Revised: * Previously, when a `RootDiskHint` resource was defined and the installation failed with the error "Requested installation disk is not part of the host's valid disks", it was difficult to determine the valid disk names that could be used as the hint. With this release, logging was added for the list of acceptable disks so that a user can quickly determine what the root disk hint should be. (link:https://issues.redhat.com/browse/OCPBUGS-43578[OCPBUGS-43578])
Original: * Previously, when you created a virtual machine (VM) and no IP addresses existed in the IP pool, the VM did not start. An error message was generated in the `virt-launcher-<vm-name>` pod, but the message was unclear as to the source of the issue. With this release, for this situation where no IP addresses exist in the IP pool, the `virt-launcher-<vm-name>` pod includes a clear error message that is similar to the following example:
Revised: * Previously, the PowerVS installer used a hard-coded list of supported machine types. However, this list was not always updated as new types were added. With this release, the `datacenter` resource is queried to get the current list of supported types. (link:https://issues.redhat.com/browse/OCPBUGS-49940[OCPBUGS-49940])
Original: * Previously, when mirroring Operators using oc-mirror plugin v2, some community Operators with long lists of `skips` and `replaces` entries in their channel graphs caused the mirroring process to run out of memory and fail. With this release, oc-mirror plugin v2 improves the filtering logic by avoiding repeated evaluation of entries referenced in multiple `skips` and `replaces` stanzas, resulting in better memory handling during Operator mirroring. (link:https://issues.redhat.com/browse/OCPBUGS-52471[OCPBUGS-52471])

[id="ocp-release-note-openshift-cli-bug-fixes_{context}"]
Revised: * Previously, a bug on `oc adm inspect --all-namespaces` command construction meant that must-gather was not correctly gathering information about leases, `csistoragecapacities` resources, and the `assisted-installer` namespace. With this release, the issue is fixed and must-gather will gather the information correctly. (link:https://issues.redhat.com/browse/OCPBUGS-44857[OCPBUGS-44857])
Original: * Previously, when the temporary control plane was down, the `networkConfig.status.ServiceNetwork` was not populated, and when generating certificated did not have the Kubernetes service IP in the SANs, the clients would fail to connect to the kube-apiserver through the default kubernetes service. With this release, a guard has been added to skip certificated generation if `networkConfig.status.ServiceNetwork` is nil. Client connections will be stable and valid. (link:https://issues.redhat.com/browse/OCPBUGS-45943[OCPBUGS-45943]) 
Revised: * Previously, when the temporary control plane was down, the `networkConfig.status.ServiceNetwork` was not populated, and when generated certificates did not have the Kubernetes service IP in the SANs, the clients would fail to connect to the kube-apiserver through the default kubernetes service. With this release, a guard has been added to skip certificated generation if `networkConfig.status.ServiceNetwork` is nil. Client connections will be stable and valid. (link:https://issues.redhat.com/browse/OCPBUGS-45943[OCPBUGS-45943])
Original: * Previously, the *Projects details page* in the *Developer Perspective* erroneously did not include breadcrumbs. With this release, the breadcrumbs have been added. (link:https://issues.redhat.com/browse/OCPBUGS-52298[OCPBUGS-52298])
Revised: * Previously, the *Projects details* page in the *Developer Perspective* erroneously did not include breadcrumbs. With this release, the breadcrumbs have been added. (link:https://issues.redhat.com/browse/OCPBUGS-52298[OCPBUGS-52298])
Original: * Previously, when opening the *Project* dropdown menu while the web terminal is open, there were visual artifacts. After this update, the artifact was fixed, so you can use the *Project* dropdown menu when the web terminal is open. (link:https://issues.redhat.com/browse/OCPBUGS-45325[(OCPBUGS-45325)])
Revised: * Previously, when opening the *Project* drop-down list while the web terminal is open, there were visual artifacts. After this update, the artifact was fixed, so you can use the *Project* drop-down list when the web terminal is open. (link:https://issues.redhat.com/browse/OCPBUGS-45325[(OCPBUGS-45325)])
Original: * Previously, a `PipelineRuns` CR that used a resolver could not be rerun on the {product-title} web console. If you attempted to rerun the CR, a `Invalid PipelineRun configuration, unable to start Pipeline.` was generated. With this release, you can now rerun a `PipelineRuns` CR that uses resolver without experience this issue. (link:https://issues.redhat.com/browse/OCPBUGS-44265[OCPBUGS-44265]) 
Revised: * Previously, a `PipelineRuns` CR that used a resolver could not be rerun on the {product-title} web console. If you attempted to rerun the CR, a `Invalid PipelineRun configuration, unable to start Pipeline.` was generated. With this release, you can now rerun a `PipelineRuns` CR that uses resolver without experiencing this issue. (link:https://issues.redhat.com/browse/OCPBUGS-44265[OCPBUGS-44265])
Original: * Previously, TaskRuns for a particular Pipelinerun were fetched based on the PipelineRun name. If any two PipelineRuns had the same name, TaskRuns for both PipelineRuns was fetched and displayed. With this release, TaskRuns for the particular PipelineRun will be fetched based on PipelineRun UID instead of PipelineRun name. (link:https://issues.redhat.com/browse/OCPBUGS-36658[OCPBUGS-36658])
Revised: * Previously, a `TaskRun` for a particular Pipelinerun was fetched based on the PipelineRun name. If any two PipelineRuns had the same name, the `TaskRun` for both PipelineRuns was fetched and displayed. With this release, the `TaskRun` for the particular PipelineRun will be fetched based on PipelineRun UID instead of PipelineRun name. (link:https://issues.redhat.com/browse/OCPBUGS-36658[OCPBUGS-36658])
Original: You can configure a custom security context directly in your `EventListener` resource definition to meet your security requirements. A custom security context can help ensure that containers run with restricted privileges and comply with {OCP} security context constraints (SCCs).
Revised: You can configure a custom security context directly in your `EventListener` custom resource (CR) to meet your security requirements. A custom security context can help ensure that containers run with restricted privileges and comply with {OCP} security context constraints (SCCs).
Original: :context: ossm-accessing-bookinfo-application-using-gateway-API
The {k8s} Gateway API deploys a gateway by creating a `Gateway` resource. In {ocp-product-title} 4.15 and later versions. If you want your cluster to use the Gateway API CRDs, you must enable the CRDs because they are disabled by default.
Revised: The {k8s} Gateway API deploys a gateway by creating a `Gateway` resource. In {ocp-product-title} 4.15 and later, {SMProductName} implements the Gateway API custom resource definitions (CRDs).  However, the CRDs themselves are not installed by default in {ocp-product-title} 4.18 and earlier. This means that in {ocp-product-title} 4.15 through 4.18, you must manually install the CRDs. Starting with {ocp-product-title} 4.19, the platform automatically installs and manages these CRDs, and you can no longer create, update, or delete them.
Original: :context: ossm-accessing-bookinfo-application-using-gateway-API
The {k8s} Gateway API deploys a gateway by creating a `Gateway` resource. In {ocp-product-title} 4.15 and later versions. If you want your cluster to use the Gateway API CRDs, you must enable the CRDs because they are disabled by default.
Revised: The {k8s} Gateway API deploys a gateway by creating a `Gateway` resource. In {ocp-product-title} 4.15 and later, {SMProductName} implements the Gateway API custom resource definitions (CRDs). However, in {ocp-product-title} 4.18 and earlier, the CRDs are not installed by default. Hence, in {ocp-product-title} 4.15 through 4.18, you must manually install the CRDs. Starting with {ocp-product-title} 4.19, these CRDs are automatically installed and managed, and you can no longer create, update, or delete them.
Original: . With the NFD controller running, generate the `NodeFeatureDiscovery` instance and add it to the cluster.
+
The `ClusterServiceVersion` specification for NFD Operator provides default values, including the NFD operand image that is part of the Operator payload. Retrieve its value by running the following command:
+
[source,terminal]
----
$ NFD_OPERAND_IMAGE=`echo $(oc get csv -n openshift-nfd -o json | jq -r '.items[0].metadata.annotations["alm-examples"]') | jq -r '.[] | select(.kind == "NodeFeatureDiscovery") | .spec.operand.image'`
----

Revised: . Optional: Add entries to the default `deviceClassWhiteList` field, to support more network adapters, such as the NVIDIA BlueField DPUs.
Original: * Previously, when adding a node in a disconnected environment using the `oc adm node-image` command, private registry images were inaccessible to the command, causing node addition failure due to image pull issues. This error occurred only if the cluster was initially installed with an installer binary downloaded from mirror.openshift.com. With this release, a fix has been implemented that enables successful image pull and node creation in disconnected environments. (link:https://issues.redhat.com/browse/OCPBUGS-53106[OCPBUGS-53106])
Revised: * Previously, if you tried to add a node to a disconnected environment using the `oc adm node-image` command, private registry images were inaccessible to the command, causing node addition failure. This error only occurred if the cluster was initially installed with an installer binary downloaded from (link:https://mirror.openshift.com/pub/)[mirror.openshift.com]. With this release, a fix has been implemented that enables successful image pull and node creation in disconnected environments. (link:https://issues.redhat.com/browse/OCPBUGS-53106[OCPBUGS-53106])
Original: |Not Available
Revised: * Previously, a bug on `oc adm inspect --all-namespaces` command construction meant that must-gather was not correctly gathering information about leases, `csistoragecapacities`, and the assisted-installer namespace. With this release, the issue is fixed and must-gather works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-44857[OCPBUGS-44857])
Original: * Previously, during image cleanup, oc-mirror plugin v2 would stop the deletion process if any error occurred while removing an image.
Revised: * Previously, during image cleanup, oc-mirror plugin v2 would stop the deletion process if any error occurred while removing an image. With this update, oc-mirror plugin v2 continues attempting to delete remaining images even after encountering errors. After the process completes, it displays a list of any failed deletions. (link:https://issues.redhat.com/browse/OCPBUGS-54653[OCPBUGS-54653])
Original: * Previously, it was possible to mirror an empty catalog during the mirror-to-disk (m2d) phase if an invalid Operator was specified in the `ImageSetConfiguration` file. This led to a failure during the subsequent disk-to-mirror (d2m) phase.
Revised: * Previously, it was possible to mirror an empty catalog during the mirror-to-disk (m2d) phase if an invalid Operator was specified in the `ImageSetConfiguration` file. This led to a failure during the subsequent disk-to-mirror (d2m) phase. With this update, oc-mirror plugin v2 prevents mirroring empty catalogs by validating operator references in the configuration, ensuring a more reliable mirroring process (link:https://issues.redhat.com/browse/OCPBUGS-52588[OCPBUGS-52588])
Original: * Previously, when using oc-mirror plugin v2 with the `--dry-run` flag, the `cluster-resources` folder inside the working directory was cleared. As a result, previously generated files such as `idms-oc-mirror.yaml` and `itms-oc-mirror.yaml` were deleted.
Revised: * Previously, when using oc-mirror plugin v2 with the `--dry-run` flag, the `cluster-resources` folder inside the working directory was cleared. As a result, previously generated files such as `idms-oc-mirror.yaml` and `itms-oc-mirror.yaml` were deleted. With this update, the `cluster-resources` folder is no longer cleared during dry-run operations, preserving any previously generated configuration files. (link:https://issues.redhat.com/browse/OCPBUGS-50963[OCPBUGS-50963])
Original: * Previously, the oc-mirror plugin v2 returned an exit status of `0` (success) even when mirroring errors occurred. As a result, oc-mirror plugin v2 run failures in automated workflows could go undetected.
Revised: * Previously, the oc-mirror plugin v2 returned an exit status of `0` (success) even when mirroring errors occurred. As a result, oc-mirror plugin v2 run failures in automated workflows could go undetected. With this update, oc-mirror plugin v2 has been updated to return a non-zero exit status when mirror failures occur. Despite this fix, users should not rely solely on the exit status in automated workflows. Users are advised to manually check the `mirroring_errors_XXX_XXX.txt` file generated by oc-mirror plugin v2 to identify any potential issues. (link:https://issues.redhat.com/browse/OCPBUGS-49880[OCPBUGS-49880])
Original: * Previously, when mirroring using an internal oc-mirror reserved keyword—such as `release-images`—in the destination or `--from` path flags, the operation could fail or behave unexpectedly.
Revised: * Previously, when mirroring using an internal oc-mirror reserved keyword, such as `release-images`, in the destination or `--from` path flags, the operation could fail or behave unexpectedly. With this update, oc-mirror plugin v2 correctly handles reserved keywords used in destination or source paths. (link:https://issues.redhat.com/browse/OCPBUGS-42862[OCPBUGS-42862])
Original: * Previously, oc-mirror plugin v2 did not display any progress output during the local cache population phase. For mirror configurations involving a large number of images, this could make the process appear unresponsive or stuck.
Revised: * Previously, when mirroring Operators using oc-mirror plugin v2, some community Operators with long lists of `skips` and `replaces` entries in their channel graphs caused the mirroring process to run out of memory and fail. With this update, oc-mirror plugin v2 improves the filtering logic by avoiding repeated evaluation of entries referenced in multiple `skips` and `replaces` stanzas, resulting in better memory handling during Operator mirroring. (link:https://issues.redhat.com/browse/OCPBUGS-52471[OCPBUGS-52471])

* Previously, oc-mirror plugin v2 did not display any progress output during the local cache population phase. For mirror configurations involving a large number of images, this could make the process appear unresponsive or stuck. With this update, a progress bar has been added to provide visibility into the cache population status for user awareness and experience. (link:https://issues.redhat.com/browse/OCPBUGS-56563[OCPBUGS-56563])