gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, the user interface in the `Observe Alerting` field displayed incorrect alert severity icons for information alerts. With this release, the alert severity icons match in the `Observe Alerting` field. As a result, alert icons match consistently, reducing potential confusion for users. (link:https://issues.redhat.com/browse/OCPBUGS-56470[OCPBUGS-56470])
Revised: * Previously, the *Observe Alerting* field displayed incorrect alert severity icons for information alerts. With this release, the alert severity icons match in the *Observe Alerting* field. As a result, alert icons match consistently, reducing potential confusion. (link:https://issues.redhat.com/browse/OCPBUGS-56470[OCPBUGS-56470])
Original: * Previously, using an unauthorized access configuration file in the `oc-mirror` command triggered an error. As a result, users encountered an `Unauthorized `error while synchronizing their image sets. With this release, the Docker configuration is updated to use a custom authorization file for authentication. Users can successfully synchronize their image sets without encountering the `Unauthorized` error. (link:https://issues.redhat.com/browse/OCPBUGS-55701[OCPBUGS-55701])
Revised: * Previously, if you used an unauthorized access configuration file in the `oc-mirror` command, an `Unauthorized` error was displayed when you synchronized your image sets. With this release, the Docker configuration is updated to use a custom authorization file for authentication. You can successfully synchronize your image sets without encountering the `Unauthorized` error. (link:https://issues.redhat.com/browse/OCPBUGS-55701[OCPBUGS-55701])
Original: * Previously, agent-based installer ignored the custom `additionalTrustBundlePolicy` parameter because of a missing field in the `install-config.yaml` file. Consequently, cluster installations sometimes did not comply with specified settings due to ignored overrides. With this release, the `additionalTrustBundlePolicy` config overrides are now properly applied in the `install-config.yaml` file for the assisted-service. As a result, you can correctly set the `additionalTrustBundlePolicy` parameter, and other installation configuration overrides are correctly applied. (link:https://issues.redhat.com/browse/OCPBUGS-57306[OCPBUGS-57306])
Revised: * Previously, agent-based installers ignored the custom `additionalTrustBundlePolicy` parameter because of a missing field in the `install-config.yaml` file. Consequently, cluster installations sometimes did not comply with specified settings due to ignored overrides. With this release, the `additionalTrustBundlePolicy` config overrides are now properly applied in the `install-config.yaml` file for the assisted-service. As a result, you can correctly set the `additionalTrustBundlePolicy` parameter, and other installation configuration overrides are correctly applied. (link:https://issues.redhat.com/browse/OCPBUGS-57306[OCPBUGS-57306])
Original: * Previously, when installing into an existing virtual private cloud (VPC) on {aws-first}, a potential mismatch could occur in the subnet information in the {aws-short} Availability Zone between the machine set custom resources for control plane nodes and their corresponding {aws-short} EC2 instances. As a consequence, where the control plane nodes were spread across three Availability Zones and one was recreated the discrepancy could result in an unbalanced control plane as two nodes occurred within the same Availability Zone. With this release, it is ensured that the subnet Availability Zone information in the machine set custom resources and in the EC2 instances match and the issue is resolved.
Revised: * Previously, when installing into an existing virtual private cloud (VPC) on {aws-first}, a potential mismatch could occur in the subnet information in the {aws-short} Availability Zone between the machine set custom resources for control plane nodes and their corresponding {aws-short} EC2 instances. As a consequence, where the control plane nodes were spread across three Availability Zones and one was recreated the discrepancy could result in an unbalanced control plane as two nodes occurred within the same Availability Zone. With this release, it is ensured that the subnet availability zone (AZ) information in the machine set custom resources and in the EC2 instances match and the issue is resolved.
Original: * Previously, the `/metrics` endpoint was not correctly parsing a bearer token from the `Authorization` header on internal Prometheus scrape requests. Consequently, the `TokenReview` failed and all the scrape requests returned a 401 response. With this release, the metrics endpoint handler is updated to correctly parse bearer tokens in the `Authorization` header for the `TokenReview`. This update resolves the `TargetDown` alert in the {product-title} web console.  (link:https://issues.redhat.com/browse/OCPBUGS-57181[OCPBUGS-57181])
Revised: * Previously, the `/metrics` endpoint was not correctly parsing a bearer token from the `Authorization` header on internal Prometheus scrape requests. Consequently, the `TokenReview` failed and all the scrape requests returned a 401 response. With this release, the metrics endpoint handler is updated to correctly parse bearer tokens in the `Authorization` header for the `TokenReview`. This update resolves the `TargetDown` alert in the {product-title} web console. (link:https://issues.redhat.com/browse/OCPBUGS-57181[OCPBUGS-57181])
Original: * Previously, when an IDMS or ICSP in the management cluster defined a source that pointed to `registry.redhat.io` or `registry.redhat.io/redhat`, and the mirror registry did not contain the required OLM catalog images, the provisioning of the `HostedCluster` object stalled due to unauthorized image pulls. As a consequence, the `HostedCluster` object was not deployed, and was blocked from pulling essential catalog images from the mirrored registry. With this release, the provisioning explicitly fails and blocks if a required image cannot be pulled due to authorization errors. In addition, the logic for registry overrides is improved to allow matches on the root of the registry, such as `registry.redhat.io`, for OLM CatalogSource image resolution. Also, a fallback mechanism is introduced to use the original image reference if the registry override does not yield a working image. As a result, the `HostedCluster` object is deployed, even in scenarios where the mirror registry lacks the required OLM catalog images, because the system correctly falls back to pull from the original source when appropriate. (link:https://issues.redhat.com/browse/OCPBUGS-56955[OCPBUGS-56955])
Revised: * Previously, when an IDMS or ICSP in the management cluster defined a source that pointed to `registry.redhat.io` or `registry.redhat.io/redhat` and the mirror registry did not contain the required OLM catalog images, the provisioning of the `HostedCluster` object stalled due to unauthorized image pulls. As a consequence, the `HostedCluster` object was not deployed, and was blocked from pulling essential catalog images from the mirrored registry. With this release, the provisioning explicitly fails and blocks if a required image cannot be pulled due to authorization errors. In addition, the logic for registry overrides is improved to allow matches on the root of the registry, such as `registry.redhat.io`, for OLM CatalogSource image resolution. Also, a fallback mechanism is introduced to use the original image reference if the registry override does not yield a working image. As a result, the `HostedCluster` object is deployed, even in scenarios where the mirror registry lacks the required OLM catalog images, because the system correctly falls back to pull from the original source when appropriate. (link:https://issues.redhat.com/browse/OCPBUGS-56955[OCPBUGS-56955])
Original: After the {ols-long} Operator is installed, configuring and deploying {ols-long} consists of three tasks. First, you create a credential secret using the credentials for your Large Language Model (LLM) provider. Next, you create the `OLSConfig` custom resource (CR) that the Operator uses to deploy the service. Finally, you verify that the {ols-short} service is operating.
Revised: After the {ols-long} Operator is installed, configuring and deploying {ols-short} consists of three tasks.
Original: After the {ols-long} Operator is installed, configuring and deploying {ols-long} consists of three tasks. First, you create a credential secret using the credentials for your Large Language Model (LLM) provider. Next, you create the `OLSConfig` custom resource (CR) that the Operator uses to deploy the service. Finally, you verify that the {ols-short} service is operating.
Revised: First, create a credential secret using the credentials for your Large Language Model (LLM) provider. Next, create the `OLSConfig` custom resource (CR) that the Operator uses to deploy the service. Finally, verify that the {ols-short} service is operating.
Original: * **AWS Trainium and Inferentia instance types now supported.** You can now use {AWS} Trainium and Inferentia instance types for your ROSA Classic clusters. For more information, see xref:../rosa_architecture/rosa_policy_service_definition/rosa-instance-types.adoc#rosa-sdpolicy-aws-instance-types[Red Hat OpenShift Service on AWS instance types].
Revised: * **AWS Trainium and Inferentia instance types now supported.** You can now use {AWS} Trainium and Inferentia instance types for your {rosa-classic} clusters. For more information, see xref:../rosa_architecture/rosa_policy_service_definition/rosa-instance-types.adoc#rosa-sdpolicy-aws-instance-types[Red Hat OpenShift Service on AWS instance types].
Original: For more information, see link:https://docs.openshift.com/container-platform/4.19/edge_computing/ztp-reference-cluster-configuration-for-vdu.html#ztp-reference-cluster-config[Recommended {sno} cluster configuration for vDU application workloads].
Apply tuning settings in the host firmware during initial deployment. For more information, see link:https://docs.openshift.com/container-platform/4.19/edge_computing/ztp-deploying-far-edge-sites.html#ztp-configuring-host-firmware-with-gitops-ztp_ztp-deploying-far-edge-sites[Managing host firmware settings with {ztp}].
Revised: For more information, see "Recommended {sno} cluster configuration for vDU application workloads".
Original: For more information, see link:https://docs.openshift.com/container-platform/4.19/edge_computing/ztp-reference-cluster-configuration-for-vdu.html#ztp-reference-cluster-config[Recommended {sno} cluster configuration for vDU application workloads].
Apply tuning settings in the host firmware during initial deployment. For more information, see link:https://docs.openshift.com/container-platform/4.19/edge_computing/ztp-deploying-far-edge-sites.html#ztp-configuring-host-firmware-with-gitops-ztp_ztp-deploying-far-edge-sites[Managing host firmware settings with {ztp}].
Revised: Apply tuning settings in the host firmware during initial deployment. For more information, see "Managing host firmware settings with {ztp}".
Original: Partition requirements are described in link:https://docs.openshift.com/container-platform/4.19/edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-shared-container-partition.html#ztp-image-based-upgrade-shared-container-partition_shared-container-partition[Configuring a shared container directory between ostree stateroots when using {ztp}].
Revised: For more information on partition requirements, see "Configuring a shared container directory between ostree stateroots when using {ztp}".
Original: For more details about node tuning with the `PerformanceProfile` CR, see link:https://docs.openshift.com/container-platform/4.19/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.html#perf-profile[Tuning nodes for low latency with the performance profile].
Revised: For more information about node tuning with the `PerformanceProfile` CR, see "Tuning nodes for low latency with the performance profile".
Original: For more information, see link:https://docs.openshift.com/container-platform/4.19/networking/hardware_networks/configuring-sriov-device.html#nw-sriov-nic-mlx-secure-boot_configuring-sriov-device[Configuring an SR-IOV network device].
Revised: For more information, see "Configuring the SR-IOV Network Operator on Mellanox cards when Secure Boot is enabled".
Original: Partition requirements are described in link:https://docs.openshift.com/container-platform/4.19/edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-shared-container-partition.html#ztp-image-based-upgrade-shared-container-partition_shared-container-partition[Configuring a shared container directory between ostree stateroots when using {ztp}].
Revised: For more information about partition requirements, see "Configuring a shared container directory between ostree stateroots when using {ztp}".
Original: In addition to the `.ko` files, the kmod image also requires the `cp` binary to be present as the `.ko` files are copied from this image to the image-loader worker pod created by the Operator. This is a minimal requirement and no other binary tool is required in the image. 
Revised: In addition to the `.ko` files, the kmod image also requires the `cp` binary to be present while the `.ko` files are copied from this image to the image-loader worker pod created by the Operator. This is a minimal requirement and no other binary tool is required in the image.
In addition to the `.ko` files, the kmod image also requires the `cp` binary to be present, because the `.ko` files are copied from this image to the image-loader worker pod created by the Operator. This is a minimal requirement and no other binary tool is required in the image.
Original: Single-AZ ROSA clusters have at least three control plane and two infrastructure nodes in the same availability zone (AZ) in the private subnet.
Multi-AZ ROSA clusters have at least three control plane nodes and three infrastructure nodes that are preconfigured for high availability, either in a single zone or across multiple zones, depending on the type of cluster you have selected. Control plane and infrastructure nodes have the same resiliency as worker nodes, with the added benefit of being managed completely by Red{nbsp}Hat.
Revised: Multi-AZ ROSA clusters have three control plane nodes and three infrastructure nodes that are preconfigured for high availability, one in each Availability Zone. Control plane and infrastructure nodes have the same resiliency as worker nodes, with the added benefit of being managed completely by Red{nbsp}Hat.
Original: * https://issues.redhat.com/browse/OSSM-9659[OSSM-9659] Previously, the {KialiProduct} used the `k8s_cluster_info` Ansible module from the `kubernetes.core` collection, which could fail in some environments with a result code of `-9`. This failure occurred during the `Get api version information from the cluster` Ansible task and prevented the operator from reconciling Kiali custom resources (CRs). Now, the fix removes the use of the `k8s_cluster_info` Ansible module to prevent this error.
Revised: * Previously, the {KialiProduct} used the `k8s_cluster_info` Ansible module from the `kubernetes.core` collection, which could fail in some environments with a result code of `-9`. This failure occurred during the `Get api version information from the cluster` Ansible task and prevented the Operator from reconciling Kiali custom resources (CRs). Now, the fix removes the use of the `k8s_cluster_info` Ansible module to prevent this error. (link:https://issues.redhat.com/browse/OSSM-9659[OSSM-9659])
Original: {op-system-base} and {microshift-short} work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. For example, an update of {microshift-short} from 4.14 to 4.16 or an update from 4.18 to 4.19 requires a {op-system-base} update. Supported configurations of {product-title} use verified releases for each together as listed in the following table:
Revised: {op-system-base} and {microshift-short} work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. For example, an update of {microshift-short} from 4.18 to 4.20 requires a {op-system-base} update. Supported configurations of {product-title} use verified releases for each together as listed in the following table:
Original: {op-system-base} and {microshift-short} work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. For example, an update of {microshift-short} from 4.14 to 4.16 or an update from 4.18 to 4.19 requires a {op-system-base} update. Supported configurations of {product-title} use verified releases for each together as listed in the following table:
Revised: ^|9.6
Original: {op-system-base} and {microshift-short} work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. For example, an update of {microshift-short} from 4.14 to 4.16 or an update from 4.18 to 4.19 requires a {op-system-base} update. Supported configurations of {product-title} use verified releases for each together as listed in the following table:
Revised: ^|4.19.0{nbsp}&#8594;{nbsp}4.19.z; 4.19{nbsp}&#8594;{nbsp}4.20
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, you now have the option to configure KMM module to not load an out-of-tree kernel driver and use the in-tree driver instead, and run only the device plugin. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-intree-modules_kernel-module-management-operator[Using in-tree modules].
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: In earlier releases, a cluster or KMM upgrade, or any other action, such as upgrading a non-default configuration like the firmware path that redeploys KMM, could create the need to reconfigure KMM. In this release, KMM configurations now remain persistent regardless of any of such actions.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-configuring-kmmo_kernel-module-management-operator[Configuring the Kernel Module Management Operator].
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * Improvements have been added to KMM so that GPU Operator vendors will not need to replicate KMM functionality in their code, but instead use KMM as is. This change greatly improves Operators' code size, tests, and reliability.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, KMM no longer uses HTTP(S) direct requests to check if a kmod image exists. Instead, CRI-O is used internally to check for the images. This mitigates the need to access container image registries directly from HTTP(S) requests and manually handle tasks, such as reading `/etc/containers/registries.conf` for mirroring configuration, accessing the image cluster resource for TLS configuration, mounting the CAs from the node, and maintaining our own cache in Hub & Spoke.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * You can now install KMM on worker nodes. Previously, it was not possible to deploy workloads on the control-plane nodes. Because the worker nodes do not have the `node-role.kubernetes.io/control-plane` or `node-role.kubernetes.io/master` labels, the Kernel Module Management Operator might need further configurations.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, the heartbeat filter for the NMC reconciler has been updated to filter the following events on nodes:
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: ** `status.conditions[]` (`NodeReady` only) and still filtering heartbeats
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, the preflight validation resource in the cluster has been modified. You can use the preflight validation to verify kernel modules to be installed on the nodes after cluster upgrades and possible kernel upgrades. Preflight validation also reports on the status and progress of each module in the cluster that it attempts or has attempted to validate. For more information, see xref:../updating/preparing_for_updates/kmm-preflight-validation.adoc#kmm-validation-kickoff_kmm-preflight-validation[Preflight validation for Kernel Module Management (KMM) Modules].
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * The `capabilities` field that refers to the Operator maturity level has been changed from `Basic Install` to `Seamless upgrades`. `Basic Install` indicates that the Operator does not have an upgrade option. This is not the case for KMM, where seamless upgrades are supported.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: ** *Cause*: Generating files with `controller-gen` generated a service called `webhook-service` that is not configurable. And, when deploying KMM with {olm-first}, OLM deploys a service for the webhook called `-service`.