From 6360814ce331bac6632a52db1f4525d81d87da7e Mon Sep 17 00:00:00 2001 From: tedaveryredhat Date: Tue, 25 Aug 2026 14:41:02 -0400 Subject: [PATCH] OSDOCS-20184:created RN template for 5-0 --- modules/rn-ocp-5-0-add-on-support-status.adoc | 6 + .../rn-ocp-release-notes-fixed-issues.adoc | 304 +--------- .../rn-ocp-release-notes-known-issues.adoc | 39 +- .../rn-ocp-release-notes-new-features.adoc | 521 ------------------ .../rn-ocp-release-notes-notable-changes.adoc | 22 +- ...rn-ocp-release-notes-removed-features.adoc | 7 +- release_notes/ocp-5-0-release-notes.adoc | 47 ++ 7 files changed, 62 insertions(+), 884 deletions(-) create mode 100644 modules/rn-ocp-5-0-add-on-support-status.adoc create mode 100644 release_notes/ocp-5-0-release-notes.adoc diff --git a/modules/rn-ocp-5-0-add-on-support-status.adoc b/modules/rn-ocp-5-0-add-on-support-status.adoc new file mode 100644 index 00000000000..8de46861496 --- /dev/null +++ b/modules/rn-ocp-5-0-add-on-support-status.adoc @@ -0,0 +1,6 @@ +:_mod-docs-content-type: CONCEPT +[id="rn-ocp-5-0-add-on-support-status_{context}"] += {product-title} layered and dependent component support and compatibility + +[role=”_abstract”] +The scope of support for layered and dependent components of {product-title} changes independently of the {product-title} version. To determine the current support status and compatibility for an add-on, refer to its release notes. For more information, see the link:https://access.redhat.com/support/policy/updates/openshift[Red Hat {product-title} Life Cycle Policy]. \ No newline at end of file diff --git a/modules/rn-ocp-release-notes-fixed-issues.adoc b/modules/rn-ocp-release-notes-fixed-issues.adoc index f16bbe869c4..a41dfff8c0f 100644 --- a/modules/rn-ocp-release-notes-fixed-issues.adoc +++ b/modules/rn-ocp-release-notes-fixed-issues.adoc @@ -2,6 +2,7 @@ [id="rn-ocp-release-notes-fixed-issues_{context}"] = Fixed issues +[role="abstract"] The following issues are fixed for this release: //Instructions: Add entries in the following format under the appropriate heading: @@ -34,44 +35,13 @@ The following issues are fixed for this release: [id="rn-ocp-release-note-api-auth-bug-fixes_{context}"] == API Server and Authentication -* Before this update, the `oc explain authentication` command displayed incorrect descriptions for the OpenID Connect (OIDC) provider fields. With this release, all field descriptions are corrected. As a result, the multiline comments are combined into a single line for improved YAML generation which provides better `oc explain` output. (link:https://redhat.atlassian.net/browse/OCPBUGS-56851[OCPBUGS-56851]) - [id="rn-ocp-release-note-bare-metal-hardware-fixed-issues_{context}"] == Bare Metal Hardware Provisioning -* Before this update, on certain baseboard management controller (BMC) firmware versions, booting a `BareMetalHost` to the target operating system from virtual media repeatedly failed. This issue affected `SuperMicro` ARM GH servers, such as the ARS-111GL-NHR, running updated firmware. On these servers, the system booted from an existing hard drive instead of the virtual media device because of a wrong boot order. Updated firmware on these platforms no longer supported `Cd` as a `BootSourceOverrideTarget` value, while `UsbCd` remained supported. As a consequence, node inspection failed during provisioning. With this update, the Bare Metal Operator uses `UsbCd` instead of `Cd` as the boot override target when booting from virtual media on affected BMC firmware. As a result, `BareMetalHost` provisioning and inspection complete successfully on `SuperMicro` ARM GH servers. (link:https://issues.redhat.com/browse/OCPBUGS-61851[OCPBUGS-61851]) - -* Before this update, when provisioning an NVIDIA DGX B200 bare-metal node using Advanced Cluster Management, the bare-metal host (BMH) could get stuck in a `Provisioning` state. With this release, the credential detection has been updated to detect missing credentials errors that were not being detected previously. (link:https://redhat.atlassian.net/browse/OCPBUGS-62309[OCPBUGS-62309]) - -* Before this update, the cluster deletion got stuck during the inspection phase due to a power off stage transition. As a consequence, the cluster was not deleted. With this release, the bare-metal host (BMH) is prevented from getting stuck during deletion in a ZTP environment. (link:https://redhat.atlassian.net/browse/OCPBUGS-65571[OCPBUGS-65571]) - -* Before this update, the resource ID for physical network interface controllers (NICs) on bare-metal machines using the HPE iLO6 system could change unpredictably when rebooting the machine. With this release, the resource ID stays the same after reboots. (link:https://redhat.atlassian.net/browse/OCPBUGS-70226[OCPBUGS-70226]) - -* Before this update, when performing a firmware update on a bare-metal machine by updating the `HostFirmwareController` configuration, if the `HostUpdatePolicy` was set to `onReboot`, the Bare Metal Operator (BMO) would sometimes fail to initiate the reboot and firmware upgrade. With this release, the BMO initiates the reboot and performs the firmware upgrade. (link:https://redhat.atlassian.net/browse/OCPBUGS-75006[OCPBUGS-75006]) - -* Before this update, when a physical network interface was enslaved to a bridge the interface and bridge shared the same MAC address. As a consequence, the provisioning interface detection would match both the interface and bridge and concatenate their names into an invalid multi-line value, which prevented the ironic service from starting. Because the ironic service could not start, workers could not PXE boot and agent-based installation failed with `SyncingFailed`. With this release, the bash text-parsing logic is replaced with a Python script using the `ip -json -d` command for structured output, which correctly selects a single interface when there are multiple matches for a MAC or IP address. As a result, agent-based installation on a bare-metal node completes successfully in bridged network configurations. (link:https://redhat.atlassian.net/browse/OCPBUGS-77528[OCPBUGS-77528]) - -* Before this update, when provisioning a bare-metal machine, if you provided a network data Secret that was missing an `nmstate` key, the network data would be discarded silently, leading to unexpected errors. With this release, if the `nmstate` key is missing, the Image Customization Controller will generate an error informing you that the `nmstate` key is required to complete provisioning. (link:https://redhat.atlassian.net/browse/OCPBUGS-77840[OCPBUGS-77840]) - -* Before this update, the bootstrap machine created during a bare-metal installation did not have a serial console log file. If the bootstrap machine failed and SSH access was not available, the logs were inaccessible. With this release, the bootstrap machine creates a serial console log file that is accessible to the must-gather diagnostic tool. (link:https://redhat.atlassian.net/browse/OCPBUGS-78589[OCPBUGS-78589]) - -* Before this update, Baremetal Operator's virtual media baseboard management controller (BMC) drivers required the `bootMACAddress` parameter for inspection, making it impossible to perform automatic MAC discovery. As a consequence, you were required to manually specify MAC addresses to inspect a bare-metal host (BMH) configured with virtual media based provisioning. With this release, the virtual media BMC drivers make the `bootMACAddress` parameter optional for hardware inspection. As a result, virtual media BMC BMHs can now be successfully created and inspected without requiring the `bootMACAddress` parameter, making it possible to discover MAC addresses automatically (for example, for use with O-Cloud Manager). Note that the `bootMACAddress` parameter is still required in install-config, installer-provisioned infrastructure (IPI) installations and assisted-installer installations. (link:https://redhat.atlassian.net/browse/OCPBUGS-78785[OCPBUGS-78785]) - -* Before this update, metrics for the Cluster Baremetal Operator were exposed on all network interfaces on a bare-metal host. With this release, the metrics are only exposed to the `localhost` interface so that the `kube-rbac-proxy` sidecar can access the metrics. (link:https://redhat.atlassian.net/browse/OCPBUGS-84924[OCPBUGS-84924]) [id="rn-ocp-release-note-cloud-compute-fixed-issues_{context}"] == Cloud Compute -* Before this update, the Machine API Provider OpenStack (MAPO) created an event for every single reconcile, even when no significant state changes like creation, update, or deletion had occurred. This excessive event generation led to significant noise in event logs, created potential performance overhead, and frequently disrupted monitoring and alerting systems. With this release, the reconcile function has been modified to capture the original `ResourceVersion` and only emit an event when the machine `ResourceVersion` changes, indicating an actual modification. Additionally, the event name was changed from `Reconciled` to `Updated` to better align with other machine API providers. As a result, MAPO no longer creates unnecessary events during reconciliation cycles, ensuring events are only recorded when a machine is actually updated. (link:https://redhat.atlassian.net/browse/OCPBUGS-67298[OCPBUGS-67298]) - -* Before this update, the Kube API Server for the bootstrap node could not reach webhooks in the Cluster API namespace. As a consequence, Technology Preview {vmw-first} clusters configured with static IP addresses failed installation. With this release, the installation program uses an updated version of the API that avoids the webhook requirement for custom resources (CRs) related to (IP Address Management) IPAM on Technology Preview clusters. As a result, {vmw-short} static IP installations succeed. (link:https://redhat.atlassian.net/browse/OCPBUGS-69434[OCPBUGS-69434]) - -* Before this update, when you used an outdated version of the`vpc-go-sdk` parameter that could not process the `any` protocol, Security Group (SG) Rules prevented the Messaging Application Programming Interface (MAPI) from creating new machines. As a consequence, older {ibm-cloud-name} SDK versions that could not process SG Rules with the 'any' protocol caused new machines to get stuck during provisioning. With this release, the {ibm-cloud-title} `vpc-go-sdk` parameter is updated to handle the 'any' protocol in SG Rules. As a result, new machines can be created in {ibm-cloud-title} because they do not get stuck during provisioning. (link:https://redhat.atlassian.net/browse/OCPBUGS-71220[OCPBUGS-71220]) - -* Before this update, {aws-short} inconsistency caused an instance ID leak because of checks that were not updated in status. As a consequence, machine creation led to instance leaks because of the inconsistent {aws-short} responses. With this release, the instance ID storage inconsistency in the machine creation is fixed. As a result, VM leaks do not occur, which ensures consistent machine creation. (link:https://redhat.atlassian.net/browse/OCPBUGS-72523[OCPBUGS-72390]) - -* Before this update, the Control Plane Machine Set Operator did not detect changes to the `throughputMib` field in the `AWSMachineProviderConfig` custom resource (CR). As a consequence, the control plane machine set had incorrect default values for this parameter and did not support increasing the throughput of gp3 storage volumes in an {aws-short} cluster. With this release, the internal API definitions used by the Control Plane Machine Set Operator are updated to recognize the `throughputMib` field. As a result, the Control Plane Machine Set Operator now identifies, reconciles, and applies changes to the `throughputMib` field. (link:https://redhat.atlassian.net/browse/OCPBUGS-74478[OCPBUGS-74478]) - // [id="rn-ocp-release-note-cloud-credential-operator-fixed-issues_{context}"] // == Cloud Credential Operator @@ -79,8 +49,6 @@ The following issues are fixed for this release: [id="rn-ocp-release-note-cluster-autoscaler-fixed-issues_{context}"] == Cluster Autoscaler -* Before this update, the cluster autoscaler processed paused node groups as if they were active, which could lead to the wrong nodes being deleted. With this release, the cluster autoscaler identifies paused node groups and does not act upon them, preventing incorrect node deletion. (link:https://redhat.atlassian.net/browse/OCPBUGS-78152[OCPBUGS-78152]) - // [id="ocp-release-note-cluster-override-admin-operator-bug-fixes_{context}"] // == Cluster Resource Override Admission Operator @@ -99,56 +67,19 @@ The following issues are fixed for this release: [id="rn-ocp-release-note-etcd-fixed-issues_{context}"] == etcd -* Before this update, the etcd Operator randomly removed control plane nodes, which caused duplication and potential cluster downtime. As a consequence, service disruptions might have caused the loss of control plane nodes in the etcd cluster. With this release, the etcd Operator prioritizes removing members in the same failure domain index, which reduces potential duplication and improves cluster stability. As a result, the etcd Operator ensures that the control plane remains stable with three nodes, which prevents potential service disruptions. (link:https://issues.redhat.com/browse/OCPBUGS-73857[OCPBUGS-73857]) - -* Before this update, the etcd Operator allowed member deletion and removed pre-drain hooks during a revision rollout. As a consequence, cluster degradation occurred during simultaneous machine deletion, causing API unavailability. With this release, the Cluster Member Removal Controller logic is updated to prevent deletion during a revision rollout. As a result, cluster degradation during the `OnDelete` rollout is fixed, ensuring smooth vertical scaling. (link:https://issues.redhat.com/browse/OCPBUGS-74151[OCPBUGS-74151]) // [id="rn-ocp-release-note-extensions-olmv1-fixed-issues_{context}"]e [id="rn-ocp-release-note-installer-fixed-issues_{context}"] == Installer -* Before this update, when you installed a cluster on {azure-first}, the installation program failed due to the use of a non-existent, user-assigned identity in the `install-config` file. As a consequence, the user-assigned identity was not found, causing the installation program to time out and fail. With this release, when you install a cluster on {azure-full}, the installation program verifies identity existence before it creates resources and the issue is resolved. (link:https://redhat.atlassian.net/browse/OCPBUGS-56846[OCPBUGS-56846]) - -* Before this update, attempting to install a cluster on {azure-first} using reserved keywords or trademarks caused the installation program to fail. Cluster names containing words such as `microsoft`, `windows`, `login`, `azure`, `office` caused errors during resource provisioning, and errors related to the resource or domain name were reported. As a consequence, users had to manually troubleshoot and identify the prohibited words while installing the cluster. With this release, the installation program validates the cluster name against 43 {azure-short} reserved words before deploying the cluster and provides clear error messages if a prohibited word is detected. As a result, installation failures are prevented before any cloud resources are created. (link:https://redhat.atlassian.net/browse/OCPBUGS-66943[OCPBUGS-66943]) - -* Before this update, if the {op-system-first} image was not explicitly specified, the installation program could not generate {azure-first} machine sets for the Hive Operator. As a consequence of the change to global marketplace images, machine sets generated by the installation program became invalid, causing Hive Operator machine pool scaling operations to fail. With this release, the installation program handles calls without an {op-system} image by using the machine API Operator default image selection and ensures the correct machine sets for the Hive Operator. (link:https://redhat.atlassian.net/browse/OCPBUGS-67310[OCPBUGS-67310]) - -* Before this update, the installation program did not support the {azure-short} Government API version `2019-11-01` for `storageAccounts`, causing the installation program to fail. As a consequence, users were unable to create clusters in {azure-short} Government environments. With this release, the {azure-short} client is updated to support the correct API version for `storageAccounts`. As a result, {azure-short} Government users can successfully create clusters while using boot diagnostics with a custom storage account. (link:https://redhat.atlassian.net/browse/OCPBUGS-67816[OCPBUGS-67816]) - -* Before this update, insufficient disk space for a large node image download prevented {product-title} 4.20.8 deployment. As a consequence, users failed to install {product-title} 4.20.8. With this release, temporary storage space for {product-title} 4.20.8 installation is increased. As a result, users can deploy {product-title} 4.20.8 with large image support. (link:https://redhat.atlassian.net/browse/OCPBUGS-70168[OCPBUGS-70168]) - -* Before this update, installing a cluster on {gcp-first} in the `us-south1` or `us-central1` regions without specifying zones in the `install-config.yaml` file caused installation failures. As a consequence, the installation program automatically selected an AI zone by default and because these specialized zones often lacked the specific machine types required for control plane and compute nodes, the installation failed. With this release, these AI zones are excluded from the installation program default zone selection logic. As a result, the installation program selects compatible zones by default. (link:https://redhat.atlassian.net/browse/OCPBUGS-74625[OCPBUGS-74625]) - -* Before this update, attempting to use custom DNS on {azure-short} Stack Hub, which is not supported, caused the custom DNS installation to fail. With this release, the installation program validates {azure-short} Stack Hub for custom DNS support, preventing unsupported installations. As a result, the installation program exits with an error message for an unsupported custom DNS on {azure-short} Stack Hub. (link:https://redhat.atlassian.net/browse/OCPBUGS-74631[OCPBUGS-74631]) - -* Before this update, the {sno} cluster's Machine Config Operator (MCO) lease acquisition was delayed due to inflated leader election timings during node reboots. As a consequence, the MCO controller took longer to acquire the lease, causing delayed configuration updates. With this release, the MCO lease acquisition time after reboots on {sno} clusters is reduced. As a result, MCO lease acquisition time is improved, enhancing cluster stability in {sno} clusters. (link:https://redhat.atlassian.net/browse/OCPBUGS-78154[OCPBUGS-78154]) - -* Before this update, {ibm-cloud-title} was unable to process new `SecurityGroup` rule types such as `any`. Also, older versions of the Software Development Kit (SDK) for the Virtual Private Cloud (VPC) could not use a VPC with these new types. As a consequence, the installation program could not set up a new VPC or use an existing VPC with the `any` protocol type. With this release, the SDK for the VPC is updated to support the new types. As a result, the `SecurityGroup` rule bug is resolved and the installation program creates a VPC with the new `SecurityGroup` rule type. (link:https://redhat.atlassian.net/browse/OCPBUGS-84088[OCPBUGS-84088]) - -* Before this update, pure DHCP deployment changes in an agent terminal user interface (TUI) did not persist due to a missing `--copy-network` flag in the `coreos-installer` utility. As a consequence, user changes in the networking configuration during DHCP deployment were lost after the first reboot. With this release, network configuration changes persist during reboot in DHCP deployments. As a result, pure DHCP deployments do not lose networking configuration changes after the first reboot in {product-title} `version 4.22.0-0.nightly-2026-04-23-021021`. (link:https://redhat.atlassian.net/browse/OCPBUGS-84129[OCPBUGS-84129]) [id="rn-ocp-release-note-kube-api-server-fixed-issues_{context}"] == Kube API Server -* Before this update, when a custom service account issuer was configured in the `Authentication` custom resource, the JSON Web Key Set (JWKS) URI defaulted to the master node IP address instead of the API load balancer URL. As a consequence, TLS certificate validation errors occurred because the certificate Subject Alternative Name (SAN) did not include the node IP. With this release, the `service-account-jwks-uri` is explicitly set to the API load balancer URL for all service account issuer configurations. As a result, clients can successfully validate certificates when using custom service account issuers. (link:https://redhat.atlassian.net/browse/OCPBUGS-46086[OCPBUGS-46086]) - -* Before this update, when a cluster domain name contained the substring `.tmp`, the static pod pruner incorrectly identified all certificates in the Kubernetes manifest directory as temporary files. As a consequence, the pruner deleted valid certificates on all control plane nodes, causing cluster failure during or after installation. With this release, the pruner correctly distinguishes temporary files from valid certificates regardless of the cluster domain name. As a result, clusters with `.tmp` in the domain name install and operate correctly. (link:https://redhat.atlassian.net/browse/OCPBUGS-62422[OCPBUGS-62422]) - -* Before this update, static pod manifests for control plane components lacked explicit priority values, causing the kubelet to treat them as low-priority during graceful node shutdown. As a consequence, control plane components on {sno}-terminated prematurely during shutdown, causing extended shutdown times, forced terminations, and potential storage corruption. With this release, explicit priority values are added to control plane static pod manifests. As a result, control plane components now remain available during graceful shutdown until all workload pods terminate, preventing storage corruption and forced shutdowns. (link:https://redhat.atlassian.net/browse/OCPBUGS-63213[OCPBUGS-63213]) - -* Before this update, the `nested-container` Security Context Constraint (SCC) used an incorrect specification for UID ranges, causing the UID ranges to be completely missing. As a consequence, pods using the `nested-container` SCC did not have the expected UID range constraints applied. With this release, the SCC correctly uses `uidRangeMin` and `uidRangeMax` fields to specify the UID range from `0` to `65534` so the `nested-container` SCC properly enforces UID range constraints. (link:https://redhat.atlassian.net/browse/OCPBUGS-76952[OCPBUGS-76952]) - -* Before this update, in FIPS-enabled clusters running {product-title} 4.20 or later, Kubernetes components such as the Kube API server experienced extremely high CPU usage during TLS 1.3 handshakes. This issue was caused by inefficient handling in the `golang-fips` TLS implementation introduced in Go 1.24. As a consequence, CPU usage for the Kube API Server increased significantly which impacted cluster stability. With this release, the `golang-fips` TLS handshake handling is optimized. As a result, Kubernetes components maintain normal CPU usage levels during TLS operations in FIPS-enabled clusters. (link:https://redhat.atlassian.net/browse/OCPBUGS-79679[OCPBUGS-79679]) - -* Before this update, clusters installed with a custom service account issuer included both the custom issuer and the default issuer during the first 24 hours. As a consequence, service account tokens included two audiences, preventing some applications from deploying unless the audience was explicitly specified. With this release, only the custom issuer is present when configured during installation. As a result, service account tokens contain a single audience, and some applications can deploy immediately. (link:https://redhat.atlassian.net/browse/OCPBUGS-85260[OCPBUGS-85260]) - -* Before this update, certificate files for the Kube APi server were not flushed to disk immediately after being written, and data could remain in memory without being persisted to storage. As a consequence, on {sno} clusters, an ungraceful shutdown could cause all Kube API server certificates to be lost, leaving the cluster unable to start. With this release, certificate writes are flushed to disk before any previous data is removed, ensuring crash durability. As a result, {sno} clusters that experience an unexpected shutdown no longer risk losing their Kube API server certificates. (link:https://redhat.atlassian.net/browse/OCPBUGS-85269[OCPBUGS-85269]) [id="rn-ocp-release-note-kube-storage-version-migrator-fixed-issues_{context}"] == Kube Storage Version Migrator -* Before this update, the storage version migrator pod did not have a node selector configured, causing it to run on worker nodes instead of control plane nodes. As a consequence, this {product-title} component did not follow the standard placement pattern for platform components. With this release, the migrator pod includes a node selector to schedule on control plane nodes. As a result, the storage version migrator pod runs on control plane nodes alongside other {product-title} components. (link:https://redhat.atlassian.net/browse/OCPBUGS-84312[OCPBUGS-84312]) - // [id="rn-ocp-release-note-kube-api-server-fixed-issues_{context}"] // == Kubernetes API Server* @@ -156,264 +87,46 @@ The following issues are fixed for this release: [id="rn-ocp-release-note-machine-config-operator-fixed-issues_{context}"] == Machine Config Operator -* Before this update, the Machine Config Operator (MCO) would default to the control plane architecture if the annotation was missing while performing boot images. For multi-arch clusters, this was causing incorrect updates. With this release, the multi-arch clusters are skipped when the arch annotation is not found. (link:https://issues.redhat.com/browse/OCPBUGS-69674[OCPBUGS-69674]) - -* Before this update, the Machine Config Operator (MCO) failed to log into vCenter during installation, which resulted in the vSphere credentials being erroneously recorded as part of the login error message. With this release, the error message has been updated to exclude sensitive details, ensuring that the MCO no longer logs credentials on login failure. (link:https://issues.redhat.com/browse/OCPBUGS-77318[OCPBUGS-77318]) - -* Before this update, faulty `vCenter` matching logic caused boot image update failures in multi center vSphere clusters. As a consequence, the Machine Config Operator (MCO) degraded when boot image updates were enabled for this scenario. With this update, the matching `vCenter` logic is fixed. As a result, boot image updates work as expected in 4.21 for multi center vSphere clusters. (link:https://redhat.atlassian.net/browse/OCPBUGS-77498[OCPBUGS-77498]) - -* Before this update, the Machine Config Operator (MCO) only enabled `systemd` units that contained explicit content, filtering out those without it. This prevented `systemd` units provided by extensions from being enabled when a `MachineConfig` object with `enabled: true` was applied after the extension was installed. With this release, the MCO has been modified to enable any `systemd` unit that either has content or an existing unit file, ensuring that extension-provided `systemd` units are correctly detected and enabled regardless of whether they are currently loaded. (link:[https://redhat.atlassian.net/browse/OCPBUGS-83874](https://redhat.atlassian.net/browse/OCPBUGS-83577)[OCPBUGS-83577]) // [id="rn-ocp-release-note-management-console-fixed-issues_{context}"] // == Management Console [id="rn-ocp-release-note-management-console-fixed-issues_{context}"] == Management Console -* Before this update, secrets containing a mix of text and binary values would trigger a runtime error in the edit form because the `stringData` initialization logic returned null when encountering any binary data. With this release, the system has been updated to retain string data as it iterates over fields, even if a binary field is encountered. This ensures that mixed-type secrets can now be edited seamlessly without causing application crashes. (link:https://redhat.atlassian.net/browse/OCPBUGS-62611[OCPBUGS-62611]) - -* Before this update, the application selector on the *Topology* page got reset to *All applications* after selecting an application. With this release, the user can successfully apply the *Application* in the *Topology* page . (link:https://issues.redhat.com/browse/OCPBUGS-62713[OCPBUGS-62713]) - -* Before this update, when you switched projects on the *Home > Events* page, events from previously selected projects accumulated in the list instead of showing events only for the currently selected project. With this release, the events list clears and refreshes when you select a different project, so you see only events from the active project. (link:https://redhat.atlassian.net/browse/OCPBUGS-63159[OCPBUGS-63159]) - -* Before this update, the keyboard shortcut navigation on the *Name* text filter was removed as part of the table update. With this release, the keyboard shortcut is restored. (link:https://issues.redhat.com/browse/OCPBUGS-63391[OCPBUGS-63391]) - -* Before this update, the `openshift-console-operator` pod did not detect when `service-CA` rotated its serving certificates, so it continued using expired certificates from its mounted file system. This caused Transport Layer Socket (TLS) validation failures and a degraded monitoring `ClusterOperator` on long-running clusters. With this release, the Console Operator honors the renewal of serving certificates, so you no longer need to manually restart the `console-operator` pod after certificate rotation. (link:https://redhat.atlassian.net/browse/OCPBUGS-63502[OCPBUGS-63502]) - -* Before this update, the OpenShift web console used an undefined template variable instead of the resolved template when detecting defaults for `MachineConfig` resources, leaving the **apiVersion** field empty. Submitting the default YAML from **Compute → MachineConfigs → Create MachineConfig** triggered a runtime error: "Cannot read properties of undefined (reading 'config')." With this release, the console correctly resolves the default template, and users can create `MachineConfig` resources without errors. (link:https://redhat.atlassian.net/browse/OCPBUGS-65678[OCPBUGS-65678]) - -* Before this update, when you created certain resources, such as `MachineConfig` or `ServiceMonitor`, from the YAML creation page, the `apiVersion` field was empty in the default YAML template, which could cause resource creation to fail. With this release, the YAML editor correctly populates the `apiVersion` field when you use default templates. (link:https://redhat.atlassian.net/browse/OCPBUGS-65765[OCPBUGS-65765]) - -* Before this update, the OpenShift console pod logged a large number of error-level messages about failed caching attempts and `context deadline exceeded` errors when transient network timeouts occurred during OAuth endpoint cache refreshes. With this release, the console pod logs transient cache refresh failures at debug level instead of error level, which reduces log noise while keeping the details accessible at debug level. (link:https://redhat.atlassian.net/browse/OCPBUGS-65828[OCPBUGS-65828]) - -* Before this update, the OpenShift console pod logged a large number of error-level messages about failed caching attempts and `context deadline exceeded` errors when transient network timeouts occurred during OAuth endpoint cache refreshes. With this release, the console pod logs transient cache refresh failures at debug level instead of error level, which reduces log noise while keeping the details accessible at debug level. -(link:https://redhat.atlassian.net/browse/OCPBUGS-65828[OCPBUGS-65828]) - -* Before this update, the console's internal OLMv1 catalog service swapped the *description* and *markdownDescription* fields when parsing file-based catalogs (FBC) served by `catalogd`, the OLM component that provides catalog content to a cluster. As a result, the service placed short plain-text descriptions in *markdownDescription* and long markdown-formatted descriptions in *description*. With this release, the service maps descriptions to the correct fields, so catalog tiles show short descriptions and operator detail views show full markdown descriptions as expected. -(link:https://redhat.atlassian.net/browse/OCPBUGS-65831[OCPBUGS-65831]) - -* Before this update, on the *Search* page, an invalid namespace was being passed through to each resource list component when *All Projects* was selected from the project selector. As a consequence, each list component displayed a 404 error. With this release, the *Search* page is updated so that it no longer passes a namespace through to these components when *All Project" is selected in the project selector. As a result, the list components do not display a 404 error. (link:https://issues.redhat.com/browse/OCPBUGS-65946[OCPBUGS-69546]) - -* Before this update, the _Trusted Artifact Signer_ and _Trusted Profile Analyzer_ quick starts did not include console-specific annotations, which could prevent you from seeing the quick starts on certain deployments. With this release, the quick starts now include the required annotations, so you can access them across all supported configurations. (link:https://redhat.atlassian.net/browse/OCPBUGS-68367[OCPBUGS-68367]) - -* Before this update, on the *PackageManifest* details page (*Installed Operators > packageserver*), when you navigated between tabs such as *YAML*, *Resources*, and *Events*, the console redirected you to the *Operand* details page and those tabs never loaded. With this release, the console correctly routes tab navigation on *PackageManifest* details so you can access all tabs as expected. (link:https://redhat.atlassian.net/browse/OCPBUGS-68376[OCPBUGS-68376]) - -* Before this update, the guided tour in the *Developer* perspective of the OpenShift web console still referred to the *Administrator* perspective, which had been renamed to *Core platform*. With this release, the guided tour shows the correct *Core platform* name. (link:https://redhat.atlassian.net/browse/OCPBUGS-69377[OCPBUGS-69377]) - -* Before this update, URLs in status card alert messages on the web console *Overview* page displayed as plain text that you couldn't click. With this release, the console converts these URLs into clickable links. (link:https://redhat.atlassian.net/browse/OCPBUGS-70329[OCPBUGS-70329]) - -* Before this update, the data used to provide tooltips in the web console YAML editor would not update after further data updates, such as when an operator is installed. With this release, the YAML editor has been updated to refresh the tooltip data every five minutes. (link:https://issues.redhat.com/browse/OCPBUGS-70340[OCPBUGS-70340]) - -* Before this update, the OpenShift web console did not pass the required properties to the status rendering component on the *DaemonSets list* page, causing the *Status* column to display "0 of pods" for all DaemonSets regardless of actual pod count. With this release, the console correctly passes the status properties, and the *Status* column accurately reflects the pod count. For example, "3 of 3 pods." (link:https://redhat.atlassian.net/browse/OCPBUGS-72260[OCPBUGS-72260]) - -* Before this update, when an admin user impersonated another user, the console displayed pages that the impersonated user was not authorized to view, such as *Home > Overview*, *Compute*, and *Administration > Cluster Settings*, because impersonation headers were not forwarded to the Kubernetes API during permission checks. With this release, impersonation headers are correctly forwarded, so the console navigation only shows pages the impersonated user has permission to access. (link:https://redhat.atlassian.net/browse/OCPBUGS-72526[OCPBUGS-72526]) - -* Before this update, when navigating to the *Software Catalog* page with the *Devfiles* category disabled, the page would show a `Devfile` related error in a disconnected cluster. With this release, this error is no longer shown. (link:https://redhat.atlassian.net/browse/OCPBUGS-72585[OCPBUGS-72585]) - -* Before this update, the OLMv1 documentation link on the *Software Catalog > Operators* page pointed to an incorrect URL. With this release, the link directs you to the correct OLMv1 extensions documentation, so you can access it directly from the *Operators* page. (link:https://redhat.atlassian.net/browse/OCPBUGS-73803[OCPBUGS-73803]) - -* Before this update, the OpenShift web console hard coded pagination labels, such as "1–10 of 100" and "1 of 10," in English instead of using the translation keys. When users set the console to a non-English locale, pagination controls on pages like *Projects*, *Pods*, *Nodes*, and *Helm Release History* remained in English. With this release, the console passes translatable strings to all pagination components, and pagination labels now display correctly in all supported languages. (link:https://redhat.atlassian.net/browse/OCPBUGS-74137[OCPBUGS-74137]) - -* Before this update, when you entered GB18030-2022 Level 3 Chinese characters (including CJK Extension I) in the *Name* field of the *Create Project* dialog, error messages rendered those characters as literal Go-style Unicode escape sequences, such as `\uXXXX` or `\UXXXXXXXX`. With this release, Unicode escape sequences in Kubernetes API error messages are properly converted, so you see the correct Chinese characters instead. -(link:https://redhat.atlassian.net/browse/OCPBUGS-74140[OCPBUGS-74140]) - -* Before this update, string literals in the `Edit pod count` and `Edit parallelism` modals were passed as props rather than using direct `t()` translation calls, which prevented them from being extracted for translation and left descriptive messages for *Workloads* actions in English even when a non-English locale was selected. With this release, these string literals have been marked for translation extraction and their corresponding translation keys have been added, ensuring that the modal descriptions now display properly localized text in all supported languages. (link:https://issues.redhat.com/browse/OCPBUGS-74349[OCPBUGS-74349]) - -* Before this update, if you didn't have `get` access on `project` resources and navigated to a dynamic plugin page with a namespace selector, the console reset your active namespace to *All projects*. With this release, the console preserves your selected namespace across navigation, even when you lack `project` access. (link:https://redhat.atlassian.net/browse/OCPBUGS-74538[OCPBUGS-74538]) - -* Before this update, when you clicked a status link, such as _failed pods_ or _not-ready nodes_, on the *Cluster inventory* card on the *Home > Overview* page, the console opened the resource list page without applying any filters, showing all resources. With this release, clicking a status link navigates you directly to the filtered resource list, displaying only the resources that match the status you selected. (link:https://redhat.atlassian.net/browse/OCPBUGS-74639[OCPBUGS-74639]) - -* Before this update, the *Subscription* details page action menu was empty. With this release, the *Subscription* details page action menu contains the relevant actions. (link:https://issues.redhat.com/browse/OCPBUGS-74647[OCPBUGS-74647]) - -* Before this update, clicking *View raw logs* when a resource log is very long would cause the console to hang while it logs the logs. With this release, a modal now appears which shows the current log download progress, which also allows cancellation of the download. (link:https://issues.redhat.com/browse/OCPBUGS-76283[OCPBUGS-76283]) - -* Before this update, clicking the *Add access* button on the *Project access* tab of project details page while in the Developer perspective would result in the disabling of the *Save* button and a potential error. With this release, the *Project access* tab works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-77415[OCPBUGS-77415]) - -* Before this update, when you subscribed to an Operator that required cloud provisioning, the console did not mark fields like *Azure Resource Group* as required, allowing you to submit the form without providing the necessary values. With this release, the console enforces these fields and prevents you from submitting the form until you complete them. (link:https://redhat.atlassian.net/browse/OCPBUGS-77658[OCPBUGS-77658]) - -* Before this update, when clicking the *Import to console* action on an OpenShift Lightspeed YAML code block (generated as part of the AI response), it correctly redirects to the *YAML import* page, but the editor was not pre-populated with the YAML. With this release, the code block is correctly populated. (link:https://issues.redhat.com/browse/OCPBUGS-77912[OCPBUGS-77912]) - -* Before this update, the pagination state persisted incorrectly when switching namespaces, causing empty table displays. With this release, pagination now resets to page 1 when switching namespaces while preserving the items-per-page preference. (link:https://issues.redhat.com/browse/OCPBUGS-78390[OCPBUGS-78390]) - -* Before this update, if you configured an external OpenID Connect (OIDC) using `ExternalOIDCWithUpstreamParity` API fields such as `cel`, `discoveryURL`, and `userValidationRules`, the Console Operator entered a *Degraded* state with _field not declared in schema_ errors. With this release, the Console Operator recognizes these fields, and your external OIDC configuration works without causing degradation. (link:https://redhat.atlassian.net/browse/OCPBUGS-78477[OCPBUGS-78477]) - -* Before this update, when you opened the _Manage available content in the Helm Chart Catalog_ quick start and copied the example `HelmChartRepository` YAML, the snippet had incorrect indentation and placed the *url* field outside of `.spec.connectionConfig`, producing invalid YAML that you could not apply. With this release, the example YAML uses the correct indentation and field nesting, so you can copy and apply it without errors. (link:https://redhat.atlassian.net/browse/OCPBUGS-79068[OCPBUGS-79068]) - -* Before this update, when you navigated to an Operator's subscription page and clicked *Uninstall*, the console displayed a `Something wrong happened` error because the action menu attempted to render before the subscription data was available. With this release, the action menu checks for the subscription data before rendering, so you can uninstall Operators without errors. (link:https://redhat.atlassian.net/browse/OCPBUGS-79525[OCPBUGS-79525]) - -* Before this update, on the *API Resource* page, the *Filter by subject* search field was visually misaligned with the *Verb* drop-down menu. With this release, these controls display on the same line as expected. (link:https://redhat.atlassian.net/browse/OCPBUGS-79678[OCPBUGS-79678]) - -* Before this update, when you clicked the *Resources* tab on an `ArgoCD` instance, the console displayed a `Model does not exist` error instead of loading the managed resources. With this release, the *Resources* tab correctly loads resources as expected. (link:https://redhat.atlassian.net/browse/OCPBUGS-80989[OCPBUGS-80989]) - -* Before this update, when you navigated to *Storage > VolumeSnapshots* or *Storage > VolumeAttributesClasses*, you saw a `Something wrong happened` error because the action menu attempted to render before the data finished loading. With this release, the action menu renders only after the data is available, and these pages load correctly. (link:https://redhat.atlassian.net/browse/OCPBUGS-81331[OCPBUGS-81331]) - -* Before this update, missing `itemsPerPage` and `perPageSuffix` properties in i18n prevented the translation of pagination strings. As a consequence, users experienced untranslated pagination controls. With this release, the pagination component strings are properly internationalized. As a result, pagination strings are translated correctly, improving the localized user experience in the OpenShift Console. (link:https://issues.redhat.com/browse/OCPBUGS-81506[OCPBUGS-81506]) - -* Before this update, an incorrect layer hierarchy occurred in the topology visual connector. As a consequence, it prevented users from dragging and creating new visual connectors between resources. With this release, the topology connector rendering has been corrected to ensure a proper layer hierarchy wrapping. As a result, users can now create visual connectors between resources in the *Topology* view. (link:https://issues.redhat.com/browse/OCPBUGS-84216[OCPBUGS-84216]) - -* Before this update, when editing secrets through the Web Console, binary data such as `JAR` or `JCEKS` keystores, was incorrectly decoded as UTF-8 text, which corrupted the binary values with replacement characters and rendered the files unusable. With this release, the Console now preserves base64-encoded binary data and passes it directly to the file input component without text conversion. Binary secret data remains intact when editing other fields in the same secret. (link:https://issues.redhat.com/browse/OCPBUGS-84594[OCPBUGS-84594]) - -* Before this update, when navigating to the resource detail pages for Shipwright components (`Build`, `BuildRun`, `BuildStrategy`, or `ClusterBuildStrategy`) with the Builds for Red Hat OpenShift Operator installed, the console would crash with React error #310. With this release, the component rendering logic has been corrected, allowing these Shipwright detail pages to load successfully without crashing. (link:https://issues.redhat.com/browse/OCPBUGS-86410[OCPBUGS-86410]) - [id="rn-ocp-release-note-monitoring-fixed-issues_{context}"] == Monitoring -* Before this update, a regression introduced in {product-title} version 4.15 impacted the `AlertingRule` logic, leading to inaccurate processing of alert definitions. This regression caused the system to generate duplicate alerts for the same event, causing it to misinterpret alert definitions and cluttered monitoring dashboards. With this release, the underlying regression has been resolved, restoring the intended behavior and logic to the `AlertingRule` component. (link:https://issues.redhat.com/browse/OCPBUGS-61262[OCPBUGS-61262]) - -* Before this update, the use of deprecated Kubernetes APIs generated significant unnecessary log noise within Prometheus, cluttering monitoring dashboards with redundant warnings. With this release, these deprecated API calls have been mitigated to reduce the log output to only one error. (link:https://redhat.atlassian.net/browse/OCPBUGS-65568[OCPBUGS-65568]) - -* Before this update, the minimal collection profile did not have the `kube_pod_labels` metric included, which affected the *Control Plane* panel in the Console dashboard. With this release, the panel works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-66069[OCPBUGS-66069]) - -* Before this update, the user workload Prometheus Operator did not validate the `webhookURL` secret reference in the MSTeams receiver configuration of the `AlertmanagerConfig` custom resource. As a consequence, an invalid or missing `webhookURL` secret could be accepted, causing the user workload `Alertmanager` to crash at runtime. With this release, the user workload Prometheus Operator validates the `webhookURL` secret for MSTeams receivers, rejecting invalid configurations before they can affect the `Alertmanager`. (link:https://issues.redhat.com/browse/OCPBUGS-67303[OCPBUGS-67303]) - -* Before this update, the `StatefulSet` controller did not automatically repair pods when the `StatefulSet` definition got reverted to a valid configuration after a roll-out brought the pods into a broken state. With this release, the Prometheus Operator has been configured to evict unready pods when it detects that there is a more recent revision of the `StatefulSet` controller. (link:https://issues.redhat.com/browse/OCPBUGS-78976[OCPBUGS-78976]) - -* Before this update, when Prometheus was configured to scrape targets using client Transport Layer Socket (TLS) certificates without a certificate authority (CA), rotating the client certificates caused Prometheus to permanently stop scraping the affected targets. Prometheus continued running but no metrics were collected from those targets until a manual restart. With this release, Prometheus correctly handles client certificate rotation when no CA is configured, and scraping continues uninterrupted after rotation. (link:https://issues.redhat.com/browse/OCPBUGS-86248[OCPBUGS-86248]) - -// [id="rn-ocp-release-note-networking-fixed-issues_{context}"] -// == Networking [id="rn-ocp-release-note-networking-fixed-issues_{context}"] == Networking -* Before this update, the default {product-title} Transport Layer Security (TLS) security profiles (Old, Intermediate, and Modern) included `TLS_CHACHA20_POLY1305_SHA256` cipher suite, which is not FIPS-compliant. On FIPS-enabled clusters, while the underlying OpenSSL library correctly disabled this cipher, the Ingress Controller (HAProxy) was still configured to offer it in its TLS 1.3 cipher list. As a consequence, TLS handshakes failed when clients prioritized `TLS_CHACHA20_POLY1305_SHA256`, even if other FIPS-compliant ciphers were available, because HAProxy attempted to negotiate the noncompliant cipher and hard-failed the connection instead of skipping to a compliant alternative. With this release, the Cluster Ingress Operator detects if a cluster is FIPS-enabled and automatically filters out noncompliant TLS 1.3 cipher suites, such as `TLS_CHACHA20_POLY1305_SHA256`, from the Ingress Controller configuration. As a result, clients on FIPS-enabled clusters successfully negotiate TLS connections by using compliant cipher suites, regardless of their initial cipher preference order. (link:https://issues.redhat.com/browse/OCPBUGS-3917[OCPBUGS-3917]) - -* Before this update, the mutual Transport Layer Socket (mTLS) configuration on the default Ingress Controller caused canary and console health checks to fail, degrading the Ingress and Console Operators due to required client certificates. With this release, the `IngressController` mTLS setup no longer breaks canary and console health checks. As a result, the mTLS setup no longer causes instability in the cluster, ensuring proper operation of the Ingress and Console Operators. (link:https://issues.redhat.com/browse/OCPBUGS-9037[OCPBUGS-9037]) - -* Before this update, the Cluster DNS Operator incorrectly reported a degraded status while compute nodes were being upgraded. As a consequence, the Operator status appeared to indicate a problem when the upgrade was progressing normally. With this release, the Cluster DNS Operator correctly distinguishes between transient and prolonged progressing states. As a result, the Operator accurately reports a progressing status instead of degraded during upgrades, unless there is a prolonged progressing status that indicates an actual degradation. (link:https://issues.redhat.com/browse/OCPBUGS-14346[OCPBUGS-14346]) - -* Before this update, the Ingress configuration `spec.domain` field could be modified after initial cluster installation. As a consequence, changing the domain value caused some cluster Operators to enter a degraded state. With this release, immutability validation prevents modifications to the Ingress configuration `spec.domain` field after it is set. As a result, the `spec.domain` field can no longer be changed, preventing cluster Operator degradation. (link:https://issues.redhat.com/browse/OCPBUGS-32275[OCPBUGS-32275]) - -* Before this update, the `baremetal-runtimecfg` component frequently probed the Kubernetes API server to maintain an up-to-date list of nodes, which degraded API server performance. As a consequence, the API server experienced performance issues. With this release, a caching mechanism reduces the number of API calls. As a result, API server performance is improved. (link:https://issues.redhat.com/browse/OCPBUGS-42805[OCPBUGS-42805]) - -* Before this update, when two `EgressIP` custom resources (CRs) used the same IP address and the OVN-Kubernetes control plane pod restarted or a node rebooted, the IP address was incorrectly assigned to more than one egress node. As a consequence, multiple egress nodes shared the same IP address, causing unpredictable routing behavior. With this release, OVN-Kubernetes ensures that only the first assigned IP address is re-assigned to an egress node, while duplicate assignments are prevented. As a result, only one egress node is assigned the IP address defined in the `EgressIP` CR, preventing address conflicts. (link:https://issues.redhat.com/browse/OCPBUGS-49368[OCPBUGS-49368]) - -* Before this update, when installing a cluster with platform type `external`, the `nodeip-configuration` systemd service was disabled. As a consequence, after a node rebooted, kubelet did not use the statically configured IP address for the {op-system} node because the `/etc/systemd/system/kubelet.service.d/20-nodenet.conf` file was missing and the `nodeip-configuration` service was not running. With this release, the Machine Config Operator (MCO) includes logic to enable the `nodeip-configuration` service for platform type `external`, similar to the existing logic for platform type `none`. As a result, the `nodeip-configuration` service is enabled on clusters with platform type `external`, and nodes maintain their statically configured IP addresses after reboots. (link:https://issues.redhat.com/browse/OCPBUGS-56717[OCPBUGS-56717]) - -* Before this update, the Cluster Ingress Operator deployed `ingress-canary` daemonsets without a mechanism to monitor the `canary-serving-cert` secret for changes. As a consequence, when the `canary-serving-cert` was automatically rotated by the `service-ca`, the `ingress-canary` pods did not reload the updated certificates, potentially leading to certificate expiry issues during the canary checks. With this release, the Cluster Ingress Operator computes a hash of the TLS secret and injects it as an annotation on the `ingress-canary` pod template. The Operator also actively watches the canary serving certificate secret for changes. As a result, when the certificate is rotated, the resulting hash change triggers a reconciliation that automatically rolls out new `ingress-canary` pods with the newly rotated certificates, preventing expiration failures. (link:https://issues.redhat.com/browse/OCPBUGS-58145[OCPBUGS-58145]) - -* Before this update, the DNS Operator reported `Progressing=True` during node reboots due to an insufficient number of available node-resolver pods. As a consequence, this could lead to false alarms and failed health checks during cluster upgrades or maintenance tasks involving node reboots. With this update, the status of the DNS Operator reporting mechanism was updated to account for node reboots. With this release, the Operator does not report a progressing state solely because of a rebooting node. As a result, the DNS Operator correctly handles node reboots without reporting an unnecessary `Progressing=True` state, reducing false positives during cluster maintenance. (link:https://issues.redhat.com/browse/OCPBUGS-62623[OCPBUGS-62623]) - -* Before this update, when a route was configured with `insecureEdgeTerminationPolicy: Redirect`, HAProxy preserved the port number from the host header, if provided, in the redirect location. As a consequence, this caused clients to attempt HTTPS connections on the unencrypted port, leading to TLS handshake failures and broken redirects. With this release, the HAProxy configuration template was updated to explicitly strip port numbers from the host header before constructing the redirect URL. As a result, HTTP to HTTPS redirects correctly omit the original port, ensuring clients connect to the standard HTTPS port (443) successfully. (link:https://issues.redhat.com/browse/OCPBUGS-65482[OCPBUGS-65482]) - -* Before this update, enabling `routingViaHost` and `ipForwarding` on HyperShift KubeVirt guest clusters caused routing conflicts when the management cluster also had `routingViaHost` enabled. As a consequence, the console and Ingress Cluster Operators became degraded, and route health checks failed from within the cluster, even though routes remained accessible from external clients. With this release, guest clusters use the subnet gateway IP as the default gateway, resolving the routing conflict. As a result, Console and Ingress Cluster Operators remain healthy when `routingViaHost` is enabled on both management and guest clusters. (link:https://issues.redhat.com/browse/OCPBUGS-65688[OCPBUGS-65688]) - -* Before this update, the router liveness probe used an HTTP backend check to monitor HAProxy health. As a consequence, when HAProxy reached its `maxconn` connection limit due to client traffic, the HTTP health check failed and Kubernetes unnecessarily restarted the router pods. With this release, the router liveness probe uses an HAProxy admin socket check instead of an HTTP backend check. As a result, router pods remain stable when HAProxy reaches its `maxconn` connection limit due to legitimate client traffic, preventing unnecessary restarts. (link:https://issues.redhat.com/browse/OCPBUGS-67161[OCPBUGS-67161]) - -* Before this update, the `IngressControllerDynamicConfigurationManager` feature gate was temporarily removed from the `TechPreviewNoUpgrade` feature set while a critical defect was being resolved. As a consequence, the Dynamic Configuration Manager feature of the router was not available even as a `TechPreviewNoUpgrade` feature. With this release, the `IngressControllerDynamicConfigurationManager` feature gate was restored to the `TechPreviewNoUpgrade` feature set. As a result, the {product-title} router includes the Dynamic Configuration Manager option on clusters that enable the `TechPreviewNoUpgrade` feature set. (link:https://issues.redhat.com/browse/OCPBUGS-67232[OCPBUGS-67232]) - -* Before this update, when a large number of nodes were added simultaneously to a cluster, the nodes hit a 300-second timeout and failed with a `context deadline exceeded` error. As a consequence, node initialization failed during large-scale cluster expansions. With this release, each network readiness for a node is determined independently. As a result, nodes become ready incrementally as they finish initializing, preventing timeout failures during large-scale node additions. (link:https://issues.redhat.com/browse/OCPBUGS-70130[OCPBUGS-70130]) - -* Before this update, a change in the `controller-runtime` library in {product-title} 4.21 caused logging not to be initialized for some of the controllers for the Cluster Ingress Operator. As a consequence, the Cluster Ingress Operator did not log controller initialization or reconciliation errors for the `gateway-labeler`, `gateway-service-dns`, and `gatewayclass` controllers. With this release, the Operator was updated to initialize logging for these controllers. As a result, the Operator logs initialization and reconciliation errors for these controllers. (link:https://issues.redhat.com/browse/OCPBUGS-70211[OCPBUGS-70211]) - -* Before this update, on dual-card boundary clock (T-BC) systems, initial clock offsets caused instability during startup. As a consequence, the Precision Time Protocol (PTP) daemon took an excessive amount of time to achieve a `Locked` state following a reboot. With this release, digital phase-locked loop (DPLL) inputs are inhibited until the source clock converges within 10ns, preventing the DPLL from attempting to lock onto unstable sources. As a result, the system achieves a stable lock significantly faster after a reboot. (link:https://issues.redhat.com/browse/OCPBUGS-71194[OCPBUGS-71194]) - -* Before this update, when the PTP Operator monitored the digital phase-locked loop (DPLL) offset, and the DPLL reached a steady state, the offset value could be temporarily below the threshold to be considered locked because of the high variability of the offset. As a consequence, the PTP boundary clock (T-BC) would announce its clock class before the ptp4l program and the DPLL reached a locked state. With this release, clock class decisions are started only after a minimum number of samples. As a result, the clock class is announced after the DPLL is stabilized. (link:https://issues.redhat.com/browse/OCPBUGS-74358[OCPBUGS-74358]) - -* Before this update, installing Gateway API CRDs from the experimental channel that belong to the `x-k8s.io group` was disallowed, being immediately blocked on any install attempt. With this release, the restriction on the `x-k8s.io` group CRDs was removed. You can now install Gateway API CRDs from the experimental channel that are part of the `x-k8s.io` group. (link:https://issues.redhat.com/browse/OCPBUGS-74693[OCPBUGS-74693]) - -* Before this update, when going into holdover a new data set was defined for `ts2phc` as it started reporting offsets, which did not meet the minimum number of samples. As a consequence, the PTP Operator incorrectly reported a `FREERUN` clock state immediately. With this release, when going into holdover the offset is calculated based on the slope defined by the holdover thresholds. As a result, the offset steadily increases until it goes over the threshold. The clock state correctly transitions from `HOLDOVER` to `HOLDOVER OUT-OF-SPEC` and finally to `FREERUN`. (link:https://issues.redhat.com/browse/OCPBUGS-77011[OCPBUGS-77011]) - -* Before this update, when a `NetworkAttachmentDefinition` (NAD) was created using a YAML manifest or the CLI, the web console displayed `Not Available` in the *Type* column, even though the network configuration worked correctly. With this release, the web console correctly parses and displays the NAD type from the resource's configuration, regardless of how the NAD type was created. -(link:https://redhat.atlassian.net/browse/OCPBUGS-77174[OCPBUGS-77174]) - -* Before this update, gateway pods used by layered products such as {rhoai-full} and Red Hat Connectivity Link did not respect the cluster-wide egress proxy configuration when attempting to pull Wasm plugins. As a consequence, in disconnected environments behind an enterprise HTTP proxy, the Gateway pods could not download required Wasm plugins. This situation resulted in HTTP 403 role-based access control (RBAC) errors and failed inference requests. With this release, the Ingress Operator configures the Istio control plane to respect the cluster-wide egress proxy configuration (`proxies.config.openshift.io/cluster`). As a result, Gateway pods successfully pull Wasm plugins in proxied environments without requiring manual configuration. (link:https://issues.redhat.com/browse/OCPBUGS-77457[OCPBUGS-77457]) - -* Before this update, a race condition in the PTP Operator caused one or more u-blox global navigation satellite system (GNSS) initialization commands to be ignored. As a consequence, u-blox GNSS was not fully initialized, leading to higher CPU load or loss of GNSS synchronization. With this release, the initialization order was fixed to remove the race condition. As a result, u-blox GNSS is fully initialized on every startup. (link:https://issues.redhat.com/browse/OCPBUGS-77480[OCPBUGS-77480]) - -* Before this update, `kube-apiserver` rollouts in user clusters with encrypted etcd caused transmission control protocol (TCP) Reset (RST) storms, resulting in application pod traffic drops. With this release, the issue is resolved, and `kube-apiserver` rollouts no longer cause traffic drops in encrypted clusters, improving service stability. (link:https://issues.redhat.com/browse/OCPBUGS-77510[OCPBUGS-77510]) - -* Before this update, an `ovnkube-controller` restart, typically occurring during a cluster upgrade, would trigger the removal of the Dynamic Host Configuration Protocol (DHCP) options for user-defined networks (UDN). This caused Virtual Machine (VM) IP addresses on the primary UDN interface to be lost once the DHCP lease timed out, as the controller failed to distinguish between its own leases and those of other controllers. With this release, the default network controller has been updated to ensure it does not inadvertently remove DHCP options belonging to external network controllers. (link:https://issues.redhat.com/browse/OCPBUGS-77759[OCPBUGS-77759]) - -* Before this update, the Cluster DNS Operator dropped the IPv6 configuration when updating the {product-title} DNS service, causing the Operator to revert from dual-stack to single-stack IPv4. As a consequence, dual-stack DNS functionality permanently broke. With this release, the Operator was updated to explicitly preserve the `ClusterIPs`, `IPFamilies`, and `IPFamilyPolicy` fields during service updates. As a result, the {product-title} DNS service correctly retains its dual-stack configuration when updated. (link:https://issues.redhat.com/browse/OCPBUGS-78085[OCPBUGS-78085]) - -* Before this update, the `gatewayapi_controller` in the Cluster Ingress Operator used `syncOnce` to set up a `GatewayClass` field indexer. If the Gateway API CRDs were not fully registered with the API server when `sync.Once` fired, the indexer setup failed permanently with no retry path. As a consequence, the Ingress Cluster Operator became stuck with no `Available`, `Progressing`, or `Degraded` status conditions reported. The stuck position could block cluster installation and health checks. This was a timing-dependent race condition, more likely in environments where CRD registration was still in progress when the Ingress Operator started, such as HyperShift hosted control planes. With this release, `sync.Once` was replaced with a retry mechanism so that the `GatewayClass` field indexer setup is retried if the initial attempt fails. As a result, the Ingress Cluster Operator correctly reports its status conditions even when Gateway API CRDs take time to register, preventing the Operator from becoming permanently stuck. (link:https://issues.redhat.com/browse/OCPBUGS-78523[OCPBUGS-78523]) - -* Before this update, when the Precision Time Protocol (PTP) management client (PMC) process was killed, PMC continuously spawned new processes until the container crashed. As a consequence, the container would restart. With this release, the PMC process restarts without spawning excessive processes. (link:https://issues.redhat.com/browse/OCPBUGS-78814[OCPBUGS-78814]) - -* Before this update, Gateway API used OpenShift Service Mesh (OSSM) 3.3.0, which contained bugs related to the `BackendTLSPolicy` CRD and other downstream issues. As a consequence, clusters using the Gateway API could experience stability and functionality issues with `BackendTLSPolicy` configurations. With this release, Gateway API was upgraded to OSSM 3.3.1 and Istio v1.28.5, resolving these issues. As a result, Gateway API operates with improved stability and correct `BackendTLSPolicy` CRD handling. (link:https://issues.redhat.com/browse/OCPBUGS-79376[OCPBUGS-79376]) - -* Before this update, when a FRR-K8s was used to learn border gateway protocol (BGP) routes from the fabric, either through the `RouteAdvertisements` feature or the MetalLB Operator concurrently with excessive pod lifecycle churn, the learned BGP routes might be uninstalled from the cluster, causing traffic that relies on those routes to fail. With this release, the underlying FRR BGP backend has been upgraded from v8 to v10, resolving the bug and ensuring that learned BGP routes remain stable and correctly installed. (link:https://issues.redhat.com/browse/OCPBUGS-84960[OCPBUGS-84960]) - -* Before this update, during control plane upgrades in zero-worker hosted clusters, the Cluster Network Operator would wait indefinitely for a worker node rollout, blocking the `ovnkube-control-plane` from updating and preventing the upgrade from completing. With this release, the Operator no longer blocks on worker rollouts when no workers are present, allowing control plane upgrades to finish successfully. (link:https://issues.redhat.com/browse/OCPBUGS-85657[OCPBUGS-85657]) - - -[id="clock-state-metrics_{context}"] -== Clock state metrics degrade correctly after upstream clock loss - [id="rn-ocp-release-note-node-fixed-issues_{context}"] == Node -* Before this update, nodes with dynamic system reserved allocation enabled, including all workers installed in 4.21 and later, could not scale down if the node only had 8 GiB of memory, the documented minimum supported worker size for {product-title}. With this release, the memory reservation scaling reserves only 1 GiB of the first 8 GiB, 6% of the next 120 GiB, and 2% of all remaining memory. As a result, nodes as small as 8 GiB are properly removed through autoscaling. (link:https://redhat.atlassian.net/browse/OCPBUGS-75869[OCPBUGS-75869]) - -* Before this update, a race condition in the container stop path could have caused CRI-O to panic with a "send on closed channel" message when a second `StopContainer` call arrived after the first had already completed and closed the internal stop channel. As a consequence, the CRI-O process crashed, potentially leaving pods stuck in a terminating state. With this release, a `stopDone` guard is added to the `WaitOnStopTimeout` method so that it returns early after the stop life cycle is complete. As a result, concurrent `StopContainer` calls do not cause a panic by sending on a closed channel. (link:https://redhat.atlassian.net/browse/OCPBUGS-76415[OCPBUGS-76415]) - -* Before this update, init containers in Tekton Pipelines finished too quickly for CRI-O to capture exit codes, causing intermittent failures in high-performance environments. As a consequence, these non-deterministic pipeline failures occurred. With this release, there is an improvement in the exit code handling of CRI-O for fast-completing init containers. As a result, high-performance Tekton Pipelines no longer intermittently fail due to non-deterministic exit code issues in init containers. (link:https://issues.redhat.com/browse/OCPBUGS-82162[OCPBUGS-82162]) - //[id="rn-ocp-release-note-node-tuning-operator-fixed-issues_{context}"] //== Node Tuning Operator -* Before this update, a failure to update the `PerformanceProfile` status due to a temporarily unavailable API server during an upgrade or under network load could leave the profile in a `Degraded` condition. As a consequence, the degraded condition might get stuck and never resolve, even after the cluster returned to a healthy state, because the operator did not retry until the next reconcile event. With this update, the operator schedules a retry of the status update until it succeeds, retrying approximately every 30 seconds. As a result, the stuck degraded condition is temporary and resolves automatically during the next retry. (link:https://issues.redhat.com/browse/OCPBUGS-62277[OCPBUGS-62277]) - -* Previously, when a `MachineConfigPool` resource was paused, the NUMA Resources Operator could enter an infinite reconciliation loop. This prevented all node groups from completing their updates, including those not associated with the paused pool. With this update, paused `MachineConfigPool` resources no longer block the operator, and node groups backed by non-paused pools continue to reconcile normally. Additionally, the `NUMAResourcesOperator` custom resource status now reports a `MachineConfigPoolPaused` condition, providing visibility into which pools are paused and might require attention. As a result, workflows that involve paused `MachineConfigPool` resources, such as canary upgrades, no longer cause the NUMA Resources Operator to stall. (link:https://issues.redhat.com/browse/OCPBUGS-84690[OCPBUGS-84690]) - [id="rn-ocp-release-note-observability-fixed-issues_{context}"] == Observability -* Before this update, when you clicked on a link that included `monitoring/graph`, you were redirected to `monitoring/query-browser` and the query parameters were not re-encoded. As a consequence, invalid queries occurred. With this release, the parameters are re-encoded to produce valid queries. (link:https://redhat.atlassian.net/browse/OCPBUGS-81567[OCPBUGS-81567]) [id="rn-ocp-release-note-oc-fixed-issues_{context}"] == oc -* Before this update, when the `oc adm must-gather` command was interrupted with *Ctrl+C*, the temporary namespace and pods were not deleted. As a consequence, these resources remained on the cluster and required manual cleanup. With this release, the command properly handles termination signals and removes temporary resources when interrupted. As a result, the temporary namespace and associated pods are cleaned up automatically unless the `--keep-namespace` flag is set. (link:https://redhat.atlassian.net/browse/OCPBUGS-59311[OCPBUGS-59311]) - -* Before this update, the `oc login` command did not apply the `insecure-skip-tls-verify` setting from the kubeconfig file to the OAuth endpoint. As a consequence, Transport Layer Socket (TLS) certificate verification failed when the OAuth endpoint had an invalid certificate or certificate chain, even though the setting was configured in the kubeconfig file. With this release, the `oc` login` command correctly applies the `insecure-skip-tls-verify` setting from the kubeconfig file to both the API server and OAuth endpoint. As a result, TLS certificate verification is skipped for the OAuth endpoint when configured in the kubeconfig file. (link:https://redhat.atlassian.net/browse/OCPBUGS-64619[OCPBUGS-64619]) - -* Before this update, the `oc adm node-image create` command attempted to contact `quay.io` first instead of using the mirror registry when generating a discovery ISO for node addition in disconnected environments. As a consequence, in environments with strict firewall restrictions, the `node-joiner` process hung waiting for a connection to `quay.io`, even though all necessary images existed in the `ImageContentSourcePolicy` (ICSP) or `ImageDigestMirrorSet` (IDMS) configuration. With this release, the `oc` client directly references mirrors defined in ICSP or IDMS before attempting to contact external registries. As a result, discovery ISO creation succeeds in disconnected environments where a proxy responds on behalf of `quay.io`, but `quay.io` itself cannot be reached. (link:https://redhat.atlassian.net/browse/OCPBUGS-64840[OCPBUGS-64840]) - -* Before this update, when using the `oc expose service` command with the `--labels` option to create a Route, the command ignored the custom labels. As a consequence, the resulting route resource used the service selector as its labels instead of the labels specified in the `--labels` option. With this release, the `oc expose service` command correctly applies custom labels from the `--labels` option to the route resource. (link:https://redhat.atlassian.net/browse/OCPBUGS-74543[OCPBUGS-74543]) - -* Before this update, the `oc adm inspect` command failed to collect resources when both the API group and resource name were specified. As a consequence, resources could only be collected by specifying the resource name without the API group. With this release, `oc adm inspect` correctly resolves resource types when both the API group and resource name are specified and resources can be collected using explicit API group specifications. (link:https://redhat.atlassian.net/browse/OCPBUGS-76958[OCPBUGS-76958]) [id="rn-ocp-release-note-oc-mirror-fixed-issues_{context}"] == oc-mirror -* Before this update, when an `ImageSetConfiguration` specified `full: true` with zero packages, the `oc-mirror` command incorrectly displayed a message about rebuilding the catalog. As a consequence, users received misleading output indicating catalog operations that were not performed. With this release, the log output omits the rebuild message for this configuration. As a result, the `oc-mirror` command displays accurate logging information when mirroring full catalogs without package filters. (link:https://redhat.atlassian.net/browse/OCPBUGS-61136[OCPBUGS-61136]) - -* Before this update, when mirroring catalogs to registries that do not support the Open Container Initiative (OCI) format, `oc-mirror` v2 failed with the error "Instructed to preserve digests." As a consequence, mirroring to old nexus versions registries was not possible. With this release, `oc-mirror` correctly handles manifest conversion for non-OCI registries. As a result, catalog mirroring to old nexus versions registries completes successfully. (link:https://redhat.atlassian.net/browse/OCPBUGS-73760[OCPBUGS-73760]) - -* Before this update, registry configuration files with explicitly set `use-sigstore-attachments: false` were incorrectly treated as unconfigured. As a consequence, `oc-mirror` generated a new configuration file instead of respecting the existing configuration. With this release, `oc-mirror` respects existing registry configuration files with `use-sigstore-attachments: false`. (link:https://redhat.atlassian.net/browse/OCPBUGS-75013[OCPBUGS-75013]) - -* Before this update, `oc-mirror` v2 failed to retrieve the user home path for users with IDs outside the expected range. As a consequence, `oc-mirror` failed in containerized environments with dynamically assigned user IDs, such as OpenShift CI, with the error "unknown userid." With this release, `oc-mirror` v2 retrieves the user home path for users with any user ID range. As a result, `oc-mirror` works in containerized environments regardless of the user ID. (link:https://redhat.atlassian.net/browse/OCPBUGS-77141[OCPBUGS-77141]) - -* Before this update, when performing disk-to-mirror operations, `oc-mirror` generated cluster resource manifests with empty status fields for `ClusterCatalog`, `CatalogSource`, and `UpdateService` resources. As a consequence, the generated YAML files contained unnecessary `status: {}` entries. With this release, `oc-mirror` no longer includes empty status fields in generated cluster resource manifests. As a result, the generated YAML files are cleaner and do not contain empty status fields. (link:https://redhat.atlassian.net/browse/OCPBUGS-77146[OCPBUGS-77146]) [id="rn-ocp-release-note-olm-fixed-issues_{context}"] == OLM -* Before this update, the `collect-profiles` job was affected by maintenance difficulties, causing confusion for customers and support engineers during troubleshooting. With this release, the `collect-profiles` job is removed, improving user experience and reducing maintenance effort. (link:https://issues.redhat.com/browse/OCPBUGS-31547[OCPBUGS-31547]) - -* Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares `RELEASE_VERSION` against the stored Operator version and sets the `Progressing=True` status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) - -* Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because {hcp} allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port` parameter, OLM Operators failed to communicate with `kube-apiserver` in hosted clusters that used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (`egress: [{}]`) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports deploying {hcp} with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) - -* Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because {hcp} allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in {hcp} clusters that used custom API ports. As a consequence, Operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports {hcp} deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) - -* Before this update, the `catalog-operator` pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) - - [id="rn-ocp-release-note-ocp-api-server-fixed-issues_{context}"] == OpenShift API Server -* Before this update, Security Context Constraints (SCCs) did not include `image` as a supported volume type. As a consequence, pods using image volumes failed to be created with the error `image volumes are not allowed to be used`. With this release, `image` is added as a supported volume type in SCCs. As a result, pods can use image volumes without security context constraint errors. (link:https://redhat.atlassian.net/browse/OCPBUGS-65807[OCPBUGS-65807]) - -[id="ocp-release-notes-web-console-fixed-issues_{context}"] -== Web console - -* Before this update, the web console displayed Guided Tours by default, even in environments where users already know {product-title}, such as shared clusters. With this release, {product-title} 4.22 cluster administrators can enable or disable Guided Tours by configuring the console `GuidedTourFeature` capability. (link:https://issues.redhat.com/browse/CONSOLE-4986[CONSOLE-4986]) - // [id="rn-ocp-release-note-ocp-cli-fixed-issues_{context}"] // == OpenShift CLI (oc) @@ -421,20 +134,11 @@ The following issues are fixed for this release: // == OpenShift Controller // [id="rn-ocp-release-note-olm-classic-fixed-issues_{context}"] -// == {olmv0-first} - -// [id="rn-ocp-release-note-service-catalog-fixed-issues_{context}"] -// == Service Catalog +// == OLM classic [id="rn-ocp-release-note-storage-fixed-issues_{context}"] == Storage -* Before this update, the vSphere container storage interface (CSI) driver Operator's metrics endpoint (port 8445) returned a _HTTP 500 Internal Server Error_ message when accessed without authentication, instead of the expected _HTTP 401 Unauthorized_ message. As a consequence, the service account lacked permission to create the `subjectaccessreviews` resources, causing the authorization check itself to fail, rather than properly rejecting the unauthorized request. With this release, the missing role-based access control (RBAC) permissions have been added to the vSphere CSI driver operator's `ClusterRole` object. (link:https://redhat.atlassian.net/browse/OCPBUGS-60159[OCPBUGS-60159]) -* Before this update, the storage operator did not create the required `RoleBinding` object for Prometheus in the `openshift-cluster-csi-drivers` namespace, which caused the monitoring of the CSI driver namespace to fail and prevented metric collection. With this release, the storage operator creates the `RoleBinding` object for the Prometheus Service Account in the `openshift-cluster-csi-drivers` namespace. As a result, CSI drivers are successfully monitored during hosted control planes AKS runs. (link:https://redhat.atlassian.net/browse/OCPBUGS-70339[OCPBUGS-70339]) - -* Before this update, after a node reboot, a pod might fail to start displaying the "Multi-Attach" error, even though the volume is not attached to any node. With this release, LUN verification was added to prevent race conditions during disk attachment. As a result, pods start successfully after a node reboot. (link:https://redhat.atlassian.net/browse/OCPBUGS-74936[OCPBUGS-74936]) - -* Before this update, creating snapshots of large {azure-first} UltraSSD_LRS or PremiumV2_LRS persistent volumes could fail due to a hard coded 10-minute timeout in the Container Storage Interface (CSI) driver, which was insufficient for Azure's background copy process on large disks. With this release, the {azure-short} Disk CSI driver supports instant access snapshots, configurable with the `instantAccessDurationMinutes` parameter in the `VolumeSnapshotClass`, allowing snapshot operations on large volumes to complete successfully. (link:https://issues.redhat.com/browse/OCPBUGS-77248[OCPBUGS-77248]) - -* Before this update, a fix for dangling volumes introduced a regression where the `ControllerUnpublish` operation could continue indefinitely when waiting for a disk's `ManagedBy` field to clear. This occurred if the disk was reassigned to another node during the detach operation, causing the wait loop to never exit because the `ManagedBy` field pointed to the new node instead of becoming NULL. With this release, the disk's `ManagedBy` field is checked to see if it points to a different node rather than the one being detached from. If so,the detach operation is considered complete, allowing volumes to properly clear the "detaching" state and be scheduled on new nodes. (link:https://redhat.atlassian.net/browse/OCPBUGS-85193[OCPBUGS-85193]) \ No newline at end of file +[id="ocp-release-notes-web-console-fixed-issues_{context}"] +== Web console \ No newline at end of file diff --git a/modules/rn-ocp-release-notes-known-issues.adoc b/modules/rn-ocp-release-notes-known-issues.adoc index 908aae4fdca..35b6bf9a962 100644 --- a/modules/rn-ocp-release-notes-known-issues.adoc +++ b/modules/rn-ocp-release-notes-known-issues.adoc @@ -2,40 +2,5 @@ [id="rn-ocp-release-notes-known-issues_{context}"] = Known issues -This section includes several known issues for {product-title} {product-version}. - -* Currently, the `topo-aware-scheduler` provided by the NUMA Resources Operator (NRO) does not support Kubernetes priority-based preemption. When all NUMA zones on available nodes are fully consumed by lower-priority pods, a high-priority pod with a `PreemptLowerPriority` policy remains in `Pending` state indefinitely instead of preempting the lower-priority pods. As a consequence, workloads that depend on priority-based preemption for scheduling recovery do not function correctly when using the `topo-aware-scheduler`. (link:https://issues.redhat.com/browse/OCPBUGS-77930[OCPBUGS-77930]) - -* Currently, on clusters with SR-IOV network virtual functions configured, a race condition might occur between system services responsible for network device renaming and the TuneD service managed by the Node Tuning Operator. As a result, the TuneD profile might become degraded after the node restarts, leading to performance degradation. As a workaround, restart the TuneD pod to restore the profile state. (link:https://issues.redhat.com/browse/OCPBUGS-41934[OCPBUGS-41934]) - -* Currently, pods that use a `guaranteed` QoS class and request whole CPUs might not restart automatically after a node reboot or kubelet restart. The issue might occur in nodes configured with a static CPU Manager policy and using the `full-pcpus-only` specification, and when most or all CPUs on the node are already allocated by such workloads. As a workaround, manually delete and re-create the affected pods. (link:https://issues.redhat.com/browse/OCPBUGS-43280[OCPBUGS-43280]) - -* On systems that use specific AMD EPYC processors, some low-level system interrupts such as `AMD-Vi` might contain CPUs in the CPU mask that overlap with CPU-pinned workloads. This behavior is due to the hardware design. These specific error-reporting interrupts are generally inactive and there is currently no known performance impact. (link:https://issues.redhat.com/browse/OCPBUGS-57787[OCPBUGS-57787]) - -* Currently, when you apply the `openshift-node-performance` PerformanceProfile with the non-RT kernel, timer migration (`kernel.timer_migration`) is not enabled. As a consequence, kernel timers such as TCP timeout and keep-alive timers can remain stuck on CPUs assigned to latency-sensitive workloads, causing unwanted interruptions to those workloads. As a workaround, enable timer migration by using a TuneD custom resource to set the `kernel.timer_migration=1` `sysctl` parameter. For more information about configuring TuneD, see link:https://access.redhat.com/solutions/5532341[Performance addons operator advanced configuration]. (link:https://issues.redhat.com/browse/OCPBUGS-86541[OCPBUGS-86541]) - -* {product-title} does not support restoring volume snapshots in a topology domain that does not have access to the datastore where the snapshot resides. You must manually schedule pods that use a persistent volume claim (PVC) that restore a snapshot to a region and zone with the snapshot. Using a shared datastore across all regions and zones meets this requirement. (link:https://issues.redhat.com/browse/OCPBUGS-84702[OCPBUGS-84702]) - -* In some {azure-first} configurations, such as {azure-short} private, public {azure-short} {product-title}, and private {azure-short} {product-title}, outbound connectivity is achieved through outbound rules that are connected to the backend address pool of the primary IP address of the VM network interface controller (NIC). Before this update, the Egress IP address was added to the public load balancer backend address pool when an `OutBoundRule` parameter was not specified. The Egress IP addresses are no longer added to the public load balancer backend pool for any {product-title} cluster hosted on {azure-short}, regardless of the existence of an `OutBoundRule` parameter. As a result, Egress IP addresses will have no outbound connectivity except for the infrastructure subnet in an {azure-short} {product-title} cluster. (link:https://redhat.atlassian.net/browse/OCPBUGS-57447[OCPBUGS-57447]) - -* When switching between PTP profiles, metrics from the previously applied profile might not be cleaned up correctly. This issue is most noticeable when changing network interfaces (NICs). To work around this problem, you can restart the pod to clean up the metrics. (link:https://issues.redhat.com/browse/OCPBUGS-66413[OCPBUGS-66413]) - -* Currently, BGP (Border Gateway Protocol) daemon fail to listen on port 179 in the `-p 0` configuration, causing a full-mesh iBGP (Interior Gateway Protocol) topology to fail in managed routing mode. To resolve this problem, disable managed routing on the default network. (link:https://issues.redhat.com/browse/OCPBUGS-84702[OCPBUGS-84702]) - -* There is a known issue with cluster user-defined network (CUDN) using no-overlay managed routing mode. In this configuration, pods have connectivity issues with remote node IPs due to dropped SYN packets when using the `outboundSNAT` parameter. This issue affects `NodePort` services, host-networked pods, and inter-node traffic when accessing a `NodePort` service with `ExternalTrafficPolicy` set to `Cluster`. There is currently no workaround available. (link:https://issues.redhat.com/browse/OCPBUGS-79682[OCPBUGS-79682]) - -* A known issue exists where the `ovn-kubernetes-control-plane` Service Account (SA) fails to create the `RouteAdvertisement` CR that is needed in the `openshift-ovn-kubernetes` namespace to enable managed routing mode. As a consequence, no-overlay mode does not work in this configuration. There is currently no workaround available. (link:https://issues.redhat.com/browse/OCPBUGS-83406[OCPBUGS-83406]) - -* In this release, users encountering an issue when creating a CUDN (cluster user-defined network) with a transport mode set to `NoOverlay`, may find that their custom resource definition (CRD) lacks the necessary `NoOverlay` configuration fields. This omission results in network failure, impacting east-west traffic paths due to the missing `NoOverlay` field in the CRD. To resolve this issue, you can use default transport mode. (link:https://redhat.atlassian.net/browse/OCPBUGS-86761) - -* When you run Cloud-native Network Functions (CNF) latency tests on an {product-title} cluster, the test might return results that exceed the latency threshold, such as 20 microseconds for cyclictest testing. This can result in intermittent test failures even when the cluster is correctly configured for low-latency workloads. As a workaround, revert the `stalld` backend to `sched_debug` to reduce the frequency and magnitude of latency spikes. (link:https://redhat.atlassian.net/browse/OCPBUGS-86339[OCPBUGS-86339]) - -* A race condition in Telecom Grandmaster (T-GM) PTP configurations can cause a 37-second offset at system startup. This occurs because `phc2sys` synchronizes the system clock before `ts2phc` has synchronized the hardware clock (PHC) from the GNSS signal. The 37-second offset corresponds to the current UTC-TAI leap second difference. This issue resolves itself once the PHC is properly synchronized from the GNSS signal. (link:https://redhat.atlassian.net/browse/OCPBUGS-85586[OCPBUGS-85586]) - -* After the cloud-event-proxy sidecar restarts, stale replay data from `linuxptp-daemon` can race with live data over the event socket. This can cause the `openshift_ptp_clock_state` metric and the aggregate `/master` SyncStateChange cloud event to remain stuck at FREERUN or HOLDOVER, even when `ptp4l` has fully recovered to LOCKED state. As a workaround, restart the `linuxptp-daemon` pods. (link:https://redhat.atlassian.net/browse/OCPBUGS-85092[OCPBUGS-85092]) - -* When a Telecom Boundary Clock (T-BC) enters holdover, the `event.sync.sync-status.synchronization-state-change` event might report FREERUN instead of HOLDOVER. This is due to an issue in the calculation of the overall node sync state. As a workaround, use the worst state from the `event.sync.ptp-status.ptp-state-change` and `event.sync.sync-status.os-clock-sync-state-change` events, which are calculated correctly. Once the clock transitions out of holdover, the events return to sync. (link:https://redhat.atlassian.net/browse/OCPBUGS-86530[OCPBUGS-86530]) - -* Deleting and recreating test workloads with a BlueField-3 NIC causes clock jumps due to inconsistent PTP synchronization. This disrupts time synchronization in test workloads. The time synchronization stabilizes when the workloads are stable. (link:https://issues.redhat.com/browse/RHEL-93579[RHEL-93579]) - -* Currently, Extended Update Support (EUS) to EUS image-based upgrades are not supported on clusters that have cert-manager installed. As a workaround, remove cert-manager before performing the image-based upgrade, and reinstall it after the upgrade completes. (link:https://issues.redhat.com/browse/OCPBUGS-86967[OCPBUGS-86967]) +[role="_abstract"] +This section includes several known issues for {product-title} {product-version}. \ No newline at end of file diff --git a/modules/rn-ocp-release-notes-new-features.adoc b/modules/rn-ocp-release-notes-new-features.adoc index aea8f886704..34f1e110045 100644 --- a/modules/rn-ocp-release-notes-new-features.adoc +++ b/modules/rn-ocp-release-notes-new-features.adoc @@ -7,14 +7,6 @@ This release adds improvements related to the following components and concepts: [id="ocp-release-notes-ai-apps_{context}"] == AI applications -[id="ocp-release-notes-ai-apps-mcp-server_{context}"] -=== MCP server for Red Hat {product-title} (Technology Preview) -{Product-title} 4.22 introduces MCP server for Red Hat {product-title} as a Technology Preview feature. - -When a problem occurs on your {product-title} cluster, you want to determine exactly what is happening, so that you can fix the issue as soon as possible. The MCP server for Red Hat {product-title} feature provides an AI tool for this purpose to quickly and easily diagnose your {product-title} cluster. - -For more information, see xref:../ai_applications/mcp_server/mcp-server-overview.adoc[MCP server for Red Hat {product-title}]. - // [id="ocp-release-notes-api_{context}"] // == API server @@ -41,30 +33,6 @@ For more information, see xref:../authentication/structured-auth-config-fields.a [id="ocp-release-notes-CVO_{context}"] == Cluster Version Operator -New `NetworkPolicy` parameter denies traffic for pods that are not host-networked:: - -A new `NetworkPolicy` parameter for the `openshift-cluster-version` namespace denies all ingress and egress traffic for pods that are not host-networked. - -// [id="ocp-release-notes-edge-computing_{context}"] -// == Edge computing - -//// -Instructions: Add entries in the following format: - -Item description:: -+ -Detailed information. -//// - -Network reconfiguration for {sno} clusters:: -+ -You can change the network configuration of a {sno} cluster without performing a full cluster redeployment by using the {lcao}. This feature supports critical edge computing scenarios such as disaster recovery and network rehoming with a stage-driven workflow that includes the ability to rollback changes on failure. -+ -You can change network properties such as node IP addresses, machine network CIDRs, default gateways, VLAN settings, and DNS servers. -+ -For more information, see xref:../edge_computing/sno_ip_configuration/cnf-understanding-sno-ip-configuration.adoc#cnf-understanding-sno-ip-configuration[Understand {sno} network reconfiguration]. - - // [id="ocp-release-notes-etcd_{context}"] // == etcd @@ -88,18 +56,6 @@ Item description:: Detailed information. //// -{olmv1} `deploymentConfig` API for cluster extension customization (Technology Preview):: -+ -The `deploymentConfig` API in the `ClusterExtension` resource enables declarative customization of Operator pod deployments, providing feature parity with `Subscription.spec.config` in {olmv0}. Configure resource limits, node placement, environment variables, volumes, affinity rules, and pod annotations when installing cluster extensions. The format is compatible with {olmv0} configurations, simplifying migration. -+ -For more information, see xref:../extensions/ce/olmv1-configuring-extensions.adoc#olmv1-deployment-config-api_olmv1-configuring-extensions[Configuring cluster extensions]. - -`ClusterObjectSet` API for safe phased rollouts (Technology Preview):: -+ -{olmv1-first} introduces the `ClusterObjectSet` API, which enables safe, phased rollouts of Kubernetes resources during ClusterExtension deployments and upgrades. A `ClusterObjectSet` object applies resources sequentially in ordered phases with built-in readiness checks, ensuring resources are created after any resources they are dependent on. -+ -For more information, see xref:../extensions/arch/operator-controller.adoc#olmv1-clusterobjectsets_operator-controller[ClusterObjectSets]. - // [id="ocp-release-notes-hcp_{context}"] // == Hosted control planes @@ -121,24 +77,10 @@ Item description:: + Detailed information. //// -The {ibm-power-name} release on {product-title} {product-version} adds improvements and new capabilities to {product-title} components:: -+ -New features on {ibm-power-name} include: -+ -* Installer-provisioned infrastructure for {ibm-power-vc-name} is now generally available. -* Enforce RSA key format for Installer-provisioned infrastructure on {ibm-power-server-name}. -* Harden the destroy logic for Installer-provisioned infrastructure on {ibm-power-server-name} to simplify removing a cluster. [id="ocp-release-notes-ibm-z-linux-one_{context}"] == IBM Z and IBM LinuxONE -The {ibm-z-name} and {ibm-linuxone-name} release on {product-title} {product-version} adds improvements and new capabilities to {product-title} components:: -+ -New features on {ibm-z-name} and {ibm-linuxone-name} include: -+ -* Enables Secrets Store CSI Driver on {ibm-z-name} -* Hosted Control Plane support for {product-title} clusters deployed on {VirtProductName} on {ibm-z-name} and {ibm-linuxone-name} - //// Instructions: Add entries in the following format: @@ -161,20 +103,6 @@ Detailed information. [id="ocp-release-notes-insights-operator_{context}"] == Insights Operator -The Insights Operator collects custom resources to improve data retrieval efficiency and system performance:: -+ -With this release, the Insights Operator now collects the `opentelemetrycollectors.opentelemetry.io` custom resource to improve data retrieval efficiency and system performance. -+ -To maintain security and prevent the collection of sensitive information, the Insights Operator applies the following constraints: -+ --- -** Resource Limit: The Insights Operator collects a maximum of five OpenTelemetry Collector custom resources from the cluster. - -** Data Masking: The Insights Operator retains only the service subsection of the `spec.config` field. It omits receivers, exporters, and other pipeline configuration details. --- -+ -These improvements allow {product-title} to better analyze the efficiency of the data gathering process and provide more precise environment insights. (link:https://redhat.atlassian.net/browse/OCPBUGS-78115[OCPBUGS-78115]) - //// Instructions: Add entries in the following format: @@ -186,125 +114,14 @@ Detailed information. [id="ocp-release-notes-install-update_{context}"] == Installation and update -Enhancements for {ibm-power-server-title}:: -+ -The {ibm-power-server-title} {cluster-capi-operator} is enhanced to `v0.12.2` in {product-title} version 4.22. Users are required to manually select the appropriate partner group in the `Contributing Group` field due to multiple partner confidential group memberships. This feature ensures compatibility, improves system performance, and maintains security by proper selection of partner groups. The result is an {product-title} deployment with improved overall performance and reliability. - -Installing a cluster on {azure-full} with a user-provisioned DNS is generally available:: -+ -You can enable a user-provisioned domain name server (DNS) instead of the default cluster-provisioned DNS solution. For example, your organization’s security policies might not allow the use of public DNS services such as {azure-first} DNS. As a result, you can manage the API and Ingress DNS records in your own system rather than adding the records to the DNS of the cloud. If you use this feature, you must provision the cluster first and then provide your own DNS solution that includes records for `api...` and `*.apps...`. -+ -Installing a cluster on {azure-short} with a user-provisioned DNS was introduced in {product-title} 4.21 with Technology Preview status. In {product-title} 4.22, it is now generally available. -+ -For more information, see xref:../installing/installing_azure/ipi/installing-azure-customizations.adoc#installation-azure-enabling-user-managed-DNS_installing-azure-customizations[Enabling a user-managed DNS] and xref:../installing/installing_azure/ipi/installing-azure-customizations.adoc#installation-azure-provisioning-own-dns-records_installing-azure-customizations[Provisioning your own DNS records]. - -OpenShift zones support for {vmw-short} host groups is generally available:: -+ -With this release, you can map {product-title} failure domains to {vmw-full} host groups. This means that you can make use of the high availability offered by a {vmw-short} stretched cluster configuration. -+ -OpenShift zones support for {vmw-short} host groups was introduced in {product-title} 4.19 with Technology Preview status. In {product-title} {product-version}, it is now generally available. -+ -For information on configuring host groups at installation, see xref:../installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-customizations.adoc#installation-vsphere-regions-zones-host-groups_installing-vsphere-installer-provisioned-customizations[VMware vSphere host group enablement]. -+ -For information on configuring host groups for existing clusters, see xref:../installing/installing_vsphere/post-install-vsphere-zones-regions-configuration.adoc#specifying-host-groups-vsphere_post-install-vsphere-zones-regions-configuration[Specifying multiple host groups for your cluster on vSphere]. - -Installing a cluster on {aws-short} European Sovereign Cloud (Technology Preview):: -+ -You can now install {product-title} on {aws-first} in the European Sovereign Cloud (EUSC) region (`eusc-de-east-1`). The {aws-short} EUSC region is separate and independent from other {aws-short} regions, with all the infrastructure located within the European Union (EU). You must specify a custom Amazon Machine Image (AMI) in the `platform.aws.defaultMachinePlatform.amiID` field of your `install-config.yaml` file. Other limitations also apply. The {aws-short} EUSC region is available as a Technology Preview feature. -+ -For more information, see xref:../installing/installing_aws/installing-aws-account.adoc#installation-aws-eusc_region_installing-aws-account[{aws-short} EUSC]. - -Installing a cluster on {gcp-first} with N4A machine types:: -+ -With this update, you can install a {product-title} cluster on {gcp-short} with N4A machine types. -+ -N4A Virtual Machines (VMs) use highly efficient Arm-based processors. N4A machines deliver exceptional performance compared to current-generation x86-based VMs, making them ideal for containerized applications and microservices on {product-title}. -+ -For more information, see xref:../installing/installing_gcp/installing-gcp-customizations.adoc#installation-gcp-tested-machine-types_installing-gcp-customizations[Tested instance types for {gcp-full}] and link:https://docs.cloud.google.com/compute/docs/general-purpose-machines#n4a_series[N4A machine series (Google documentation)]. - -Installing a cluster using {op-system-base-full} 10:: -+ -With this update, you can install a cluster using {op-system-base} version 10 as the base image for all machines in the cluster. This feature is available as a Technology Preview. To enable this feature, enable the `TechPreviewNoUpgrade` feature set and set the `osImageStream` parameter to `rhel-10` in your `install-config.yaml` file. -+ -For more information, see xref:../installing/install_config/installation-config-parameters-generic.adoc#installation-config-parameters-generic[Installation configuration parameters]. - -Adding custom alerts to `oc adm upgrade recommend` command output:: -+ -With this update, you can add the `openShiftUpdatePrecheck` label to alerts in a `PrometheusRule` custom resource (CR) so that, when you run the `oc adm upgrade recommend` command, any firing alerts with this label appear in the command output. -+ -For more information, see xref:../updating/preparing_for_updates/updating-cluster-prepare.adoc#oc-adm-upgrade-recommend-custom-alert_updating-cluster-prepare[Adding custom alerts to `oc adm upgrade recommend` command output]. - -Deploying virtualized control planes with KubeVirt Redfish (Technology Preview):: -+ -You can use KubeVirt Redfish to deploy {product-title} clusters with control plane nodes running as virtual machines on a hosting cluster with {VirtProductName}. Running control plane nodes as VMs provides VM-level isolation for control plane components. KubeVirt Redfish exposes VMs through the standard Redfish API, enabling existing installation methods such as installer-provisioned infrastructure, Agent-based Installer, and {ztp-first} to manage VM power states and boot media. The feature is available as a Technology Preview. -+ -For more information, see xref:../vcp/vcp-overview.adoc#vcp-overview[Understanding virtualized control planes]. - -Bucketless workload identity for {gcp-short} clusters:: -+ -When installing or upgrading an {product-title} cluster on {gcp-first} with short-term credentials, you can now use the `--key-storage-method=pool-jwk-file` option with the `ccoctl gcp create-all` command to attach OIDC signing keys directly to the workload identity pool provider. This method eliminates the need to create a publicly accessible Google Cloud Storage (GCS) bucket for OIDC configuration, which reduces the public attack surface and can help meet security and network policies in restricted environments. -+ -For more information, see xref:../installing/installing_gcp/installing-gcp-customizations.adoc#cco-ccoctl-creating-at-once_installing-gcp-customizations[Creating GCP resources with the Cloud Credential Operator utility]. [id="ocp-release-notes-machine-config-operator_{context}"] == Machine Config Operator -Boot nodes into a custom machine config pool:: -+ -With this update, you can boot new nodes directly into a custom machine config pool. Before this update, you needed to create the node in the worker machine config pool, then move the node into the custom machine config pool, which requires a node reboot. By launching the node directly into the new pool, you save a node reboot cycle. -+ -For information, see xref:../machine_configuration/machine-config-custom-mcp.adoc#machine-config-custom-mcp-automatic_machine-config-creating-custom-mcp[Creating a custom machine config pool with a new node]. - -Boot image skew enforcement:: -+ -With this update, the Machine Config Operator (MCO) examines the boot image version reported in the `MachineConfiguration` object to determine if that boot image is appropriate for the cluster. If the boot image version is too old, the Operator reports that boot image version skew is detected and blocks cluster updates until you manually update the boot image or disable boot image skew enforcement. -+ -For more information, see xref:../machine_configuration/mco-update-boot-skew-mgmt.adoc#mco-update-boot-skew-mgmt[Boot image skew enforcement]. - -Boot image management for control plane nodes is generally available:: -+ -With this update, the boot image management feature for control plane nodes is generally available. With boot image management enabled, you can configure your cluster to update the node boot image whenever you update your cluster. Before this update, boot image management was supported for worker nodes only. Boot image management for control plane nodes was introduced in {product-title} 4.21 for {aws-short}, {gcp-short}, and {azure-short} clusters, and is now generally available for the platforms in 4.22. The boot image management feature for control plane nodes is not supported for {vmw-first}. -+ -For more information, see xref:../machine_configuration/mco-update-boot-images.adoc#machine-configs-configure[Boot image management]. - -Boot image management for worker nodes is now default for {azure-short} and {vmw-short}:: -+ -With this update, the boot image management feature for worker nodes is default behavior in {azure-short} and {vmw-short} clusters. As such, after updating to {product-title} 4.22, the boot images in your cluster are automatically updated to version 4.22. With subsequent updates, the Machine Config Operator (MCO) again updates the boot images in your cluster. Any new nodes you create after updating are based on the new version. Current nodes are not affected by this feature. -+ -Before updating to 4.22, you must acknowledge this change or opt-out of this default behavior before proceeding. For information on opting out, see xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images-disable_machine-configs-configure[Disabling boot image management]. -+ -For more information on the boot image management feature, see xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images_machine-configs-configure[Boot image management]. - -Boot image update documentation:: -+ -With this update, the Machine Config Operator documentation contains procedures to update the boot image on compute nodes for most supported {product-title} platforms. -+ -For {product-title} platforms that do not support automatic boot image updating or for clusters configured with the boot image management feature disabled, you can manually update the boot image used by the compute nodes in your cluster. -+ -For more information, see xref:../machine_configuration/mco-update-boot-images-manual.adoc#mco-update-boot-images-manual[Manually updating the boot image]. - -`AppliedFilesAndOS` machine config node condition is now `AppliedFiles` and `AppliedOSImage` (Technology Preview):: -+ -With this update, the `AppliedFilesAndOS` condition reported by the machine config node has been split into the `AppliedFiles` and `AppliedOSImage` conditions as a Technology Preview feature. The machine config nodes custom resource monitors the progress of machine configuration updates to nodes. The `AppliedFiles` condition reports whether MCO has updated files on the node. The `AppliedOSImage` condition reports whether the MCO has updated the operating system. -+ -For more information, see xref:../machine_configuration/index.html#checking-mco-node-status_machine-config-overview[About node status during updates]. [id="ocp-release-notes-machine-management_{context}"] == Machine management -{aws-short} Dedicated Host support (Technology Preview):: -+ -You can now place compute machines on {aws-first} Dedicated Hosts. Dedicated Hosts are physical servers that are fully dedicated to your use. With Dedicated Hosts, you can use your existing per-socket, per-core, or per-VM software licenses and comply with corporate policies that require physical CPU assignment. -+ -You can configure Dedicated Host placement in the following ways: -+ --- -* At installation, you can specify Dedicated Host IDs in the `install-config.yaml` file to place compute machines on specific Dedicated Hosts. -* After installation, you can use the Machine API or the Cluster API to place machines on Dedicated Hosts by using dynamic host allocation or by specifying individual Dedicated Host IDs. --- -+ -For more information, see xref:../installing/installing_aws/installation-config-parameters-aws.adoc#installation-config-parameters-aws[Installation configuration parameters for {aws-short}], xref:../machine_management/creating_machinesets/creating-machineset-aws.adoc#machineset-dedicated-hosts_creating-machineset-aws[Machine sets that place machines on Dedicated Hosts], and xref:../machine_management/cluster_api_machine_management/cluster_api_provider_configurations/cluster-api-config-options-aws.adoc#machine-feature-aws-dedicated-hosts_cluster-api-config-options-aws[Place machines on Dedicated Hosts by using machine templates]. - // id="ocp-release-notes-monitoring_{context}"] // == Monitoring @@ -314,203 +131,10 @@ For more information, see xref:../installing/installing_aws/installation-config- [id="ocp-release-notes-networking_{context}"] == Networking -HAProxy version update to 2.8.18:: -+ -{product-title} {product-version} now uses HAProxy version 2.8.18. With this update, the Ingress Controller benefits from the latest bug fixes and performance improvements in HAProxy. For more information about the changes in this version, see the link:https://www.haproxy.org/download/2.8/src/CHANGELOG[HAProxy 2.8.18 release notes]. - -Network policy enhancement:: -+ -To reduce the cluster attack surface and ensure predictable network behavior, {product-title} now enforces least-privilege network policies on critical networking components. Starting in 4.22, {product-title} includes default `NetworkPolicy` objects in some of its own namespaces. Specifically, the operators that manage cluster DNS and cluster Ingress automatically install and maintain default deny-all `NetworkPolicy` objects in their respective namespaces. -+ -[IMPORTANT] -==== -Because these namespaces now operate on a deny-by-default model, any unmanaged or custom pods running in these namespaces will have their network traffic blocked. Do not modify the default `NetworkPolicy` objects that {product-title} includes in its own namespaces by default. -==== -+ -To check the namespaces that include the objects by default, you can run the following command: -+ -[source,terminal] ----- -$ oc get networkpolicies --all-namespaces ----- -+ -The {product-title} {product-version} release did not include these objects in all {product-title} namespaces; later {product-title} releases might include the objects in additional namespaces. - -IPv4 forwarding for specific network interfaces:: -+ -You can enable IPv4 forwarding on specific network interfaces by using the Kubernetes NMState Operator. By setting the `forwarding: true` field in a `NodeNetworkConfigurationPolicy` custom resource, you can configure individual interfaces to forward IP packets without enabling global IP forwarding on the cluster. This approach improves security by keeping global forwarding disabled while allowing forwarding only on the interfaces that require it, such as secondary interfaces used by MetalLB load balancers. -+ -For more information, see xref:../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#nw-nmstate-enable-per-interface-ip-forwarding_k8s-nmstate-updating-node-network-config[Enable IP forwarding on specific interfaces]. - -Kubernetes NMState Operator extends metrics support:: -+ -The Kubernetes NMState Operator can now collect metrics from the following Kubernetes components: -+ -* `kubernetes_nmstate_policies_status`, which tracks the active status of `NodeNetworkConfigurationPolicy` (NNCP) resources across the cluster. -+ -* `kubernetes_nmstate_enactments_status`, which tracks the active status of `NodeNetworkConfigurationEnactment` (NNCE) resources on a per-node basis. -+ -For more information, see xref:../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#viewing-stats-collected-kubernetes-nmstate-op_k8s-nmstate-about-the-k8s-nmstate-operator[Viewing metrics collected by the Kubernetes NMState Operator]. - -Alternative interface names for network interfaces with the Kubernetes NMState Operator:: -+ -Assign alternative names to network interfaces by using the Kubernetes NMState Operator. Alternative names provide consistent, descriptive labels for interfaces across cluster nodes, simplifying automation in environments where interface names vary across nodes. -+ -For more information, see xref:../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#k8s-nmstate-alternative-interface-names_k8s-nmstate-updating-node-network-config[Configure alternative network interface names]. - -Ingress firewall configuration with the `commatrix` plugin:: -+ -The `commatrix` plugin generates `nftables` firewall rules in Butane format for deployment to cluster nodes. These rules restrict ingress traffic to only the flows required by deployed services, promoting a zero-trust security posture. The plugin also generates a `NodeDisruptionPolicy` patch to apply rule updates without node reboots. -+ -For more information, see xref:../installing/install_config/configuring-firewall.adoc#commatrix-generate-butane_configuring-firewall[Generate nftables firewall rules in Butane format]. - -// TELCODOCS-2613 -MetalLB ConfigurationState resource reports controller and speaker configuration health:: -+ -You can now use the new `ConfigurationState` custom resource to verify that MetalLB has successfully applied your settings across the cluster. This feature provides a single, consistent location to identify configuration errors that were previously only visible by searching through individual node logs or FRR status reports -+ -MetalLB creates a `ConfigurationState` resource for the controller and for each speaker node. Each resource reports whether your configuration is valid and surfaces specific error details if validation fails, such as issues with `IPAddressPool`, `BGPPeer`, or `BFDProfile` objects. This centralized reporting helps you monitor system integrity and resolve networking conflicts more quickly. -+ -For more information, see xref:../networking/ingress_load_balancing/metallb/monitoring-metallb-status.adoc#nw-metallb-checking-configuration-status_monitor-metallb-config-status[Checking MetalLB configuration status]. - -// TELCODOCS-2493 -SR-IOV Network Operator reports Ready conditions on key custom resources:: -+ -You can now monitor the health of SR-IOV Network Operator resources by using a standard `Ready` condition on `SriovNetwork`, `SriovIBNetwork`, and `SriovOperatorConfig` custom resources. Use the OpenShift CLI (`oc`) to inspect the condition status, wait for the `Ready` condition to be `True`, and troubleshoot provisioning or configuration failures from the condition `reason` and `message` fields. -+ -For more information, see xref:../networking/networking_operators/sr-iov-operator/configuring-sriov-operator.adoc#nw-sriov-about-k8s-conditions_configuring-sriov-operator[About Ready conditions for the SR-IOV Network Operator]. - -// TELCODOCS-2565 -Multi-network policy backend uses nftables:: -+ -With this release, the multi-network policy backend uses `nftables` instead of `iptables`. The `iptables` backend has been removed and there is no option to revert to it. The `MultiNetworkPolicy` API and user-facing configuration are unchanged, so your existing multi-network policies continue to work without modification. -+ -For more information, see xref:../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#configuring-multi-network-policy[Configuring multi-network policy]. - -Tune MetalLB advertisements for individual LoadBalancer services using service labels:: -+ -With MetalLB, you can now set `spec.serviceSelectors` on `BGPAdvertisement` and `L2Advertisement` custom resources (CRs). -This allows you to match LoadBalancer services by label so each advertisement applies its own BGP or Layer 2 settings to the services you choose, even when those services use the same IPAddressPool. -+ -For more information, see xref:../networking/ingress_load_balancing/metallb/about-advertising-ipaddresspool.adoc#about-advertise-for-ipaddress-pools[About advertising for the IP address pools]. - -Immutable AWS Network Load Balancer for a service:: -With this release, when deploying a service with the AWS Load Balancer the `service.beta.kubernetes.io/aws-load-balancer-type` annotation is immutable for existing services. To change the load balancer type, you must recreate the service. - -BGP EVPN for cluster user-defined networks:: -+ -With this release, Border Gateway Protocol Ethernet Virtual Private Network (BGP EVPN) is available for primary cluster user-defined networks. Enabling this feature on {product-title} allows a `ClusterUserDefinedNetwork` overlay network to use the EVPN control plane for deeper integration with the data center network. -+ -For more information, see xref:../networking/advanced_networking/bgp_evpn_udn/about-bgp-evpn-user-defined-networks.adoc#about-bgp-evpn-user-defined-networks[About BGP EVPN for primary cluster user-defined networks]. - -NoOverlay mode with BGP routing:: -+ -With this release, no-overlay mode with Border Gateway Protocol (BGP) routing is available as a Technology Preview feature on bare-metal clusters that use OVN-Kubernetes. No-overlay mode forwards layer 3 pod traffic on the underlay network using BGP-learned routes instead of Geneve encapsulation, which can improve east-west performance. You can enable no-overlay mode on the default layer 3cluster network and on primary `ClusterUserDefinedNetwork` resources. -+ -For more information, see xref:../networking/advanced_networking/bgp_routing/no-overlay-mode-bgp-routing.adoc#no-overlay-mode-bgp-routing[Improve east-west performance by routing pods on the underlay with BGP]. - -// TELCODOCS-2607 -Support for PTP boundary clock without holdover on Intel Granite Rapids-D hardware:: -+ -You can now configure Precision Time Protocol (PTP) boundary clock (BC) without holdover on Intel Granite Rapids-D (GNR-D) hardware that uses onboard Network Acceleration Complex (NAC) ports and optional Carter Flat expansion network interface cards (NICs). -+ -In this deployment, one time receiver (TR) port synchronizes to an upstream timing source while time transmitter (TT) ports distribute synchronized time downstream. GNR-D BC without holdover deployments on Carter Flat hardware require a continuous upstream PTP timing source because monitored holdover is not supported. -+ -For more information, see xref:../networking/advanced_networking/ptp/configuring-ptp.adoc#nw-ptp-granite-rapids-boundary-clock-overview_configuring-ptp[Boundary clocks without holdover on Intel Granite Rapids-D hardware]. - -// TELCODOCS-2488 -Support for Granite Rapids-D (GNR-D) telecom boundary clock with holdover on an Intel GNR-D platform (Technology Preview):: -+ -You can configure an Intel® Granite Rapids-D (GNR-D) platform device as telecom boundary clock (T-BC) with holdover support by using the PTP Operator. -+ -With this technology preview feature, you can configure T-BC holdover on GNR-D platforms `dell/XR8720t` and `hpe/EL140-Gen12`. -+ -In this configuration, one time receiver (TR) port synchronizes to an upstream telecom grandmaster clock, while time transmitter (TT) ports distribute synchronized time to downstream devices. If the upstream timing source degrades, disconnects, or becomes unavailable, the system enters holdover mode and maintains timing by using configured digital phase-locked loop (DPLL) devices. -+ -For more information, see xref:../networking/advanced_networking/ptp/configuring-ptp.adoc#nw-ptp-gnrd-t-bc-holdover_configuring-ptp[Configuring GNR-D T-BC holdover on a GNR-D platform]. - -PTP Telecom Grandmaster on Intel Granite Rapids-D (Technology Preview):: -+ -You can configure a Precision Time Protocol (PTP) Telecom Grandmaster (T-GM) on Intel Granite Rapids-D (GNR-D) servers so a single Global Navigation Satellite System (GNSS) feed synchronizes timing across onboard Network Acceleration Complex (NAC) ports and optional Carter Flat expansion network interface cards (NICs). -The PTP Operator supports GNR-D deployments with the `e830` and `e825` hardware plugins and an example `PtpConfig` custom resource (CR) that you customize for your qualified hardware layout. -PTP T-GM on GNR-D is available as a Technology Preview feature. -+ -For more information, see xref:../networking/advanced_networking/ptp/configuring-ptp.adoc#nw-ptp-granite-rapids-telecom-grandmaster-clock-overview_configuring-ptp[Telecom Grandmaster clocks on Intel Granite Rapids-D hardware]. - -// TELCODOCS-2917 -High availability for PTP boundary clocks with dual time receiver ports on Intel E810 hardware:: -+ -You can configure dual time receiver (TR) ports on a single Intel Westport Channel E810-XXVDA4T network interface card (NIC) for Precision Time Protocol (PTP) Telecom Boundary Clock (T-BC) high availability. This configuration uses the Alternate Best Master Clock Algorithm (A-BMCA) to support automatic switchover between the upstream paths if the active port goes down or its quality degrades. As a result, downstream devices maintain continuous time synchronization without manual intervention during upstream path failures. -+ -The `PtpConfig` custom resource (CR) uses a two-profile architecture with a time receiver profile and a time transmitter profile on separate PTP domains. Both TR ports share the same Physical Hardware Clock (PHC), so failover relies on A-BMCA reselection rather than switching between separate clock servos. -+ -For more information, see xref:../networking/advanced_networking/ptp/configuring-ptp.adoc#ptp-configuring-linuxptp-services-dual-port-bc_configuring-ptp[Configuring PTP boundary clock high availability with dual time receiver ports]. [id="ocp-release-notes-nodes_{context}"] == Nodes -Image pull credential verification in multi-tenant clusters:: -+ -With this update, administrators can use the `imagePullCredentialsVerificationPolicy` parameter in a `KubeletConfig` custom resource to enforce credential verification for cached images. This parameter forces the kubelet to re-authenticate with the container registry before it deploys a pod, ensuring that the requesting namespace has valid access rights to the image. -+ -The underlying `KubeletEnsureSecretPulledImages` feature gate is enabled by default. Administrators can configure specific credential provider policies to balance security and stability: -+ -* `AlwaysVerify`: Enforces credential checks for all image pull requests. -* `NeverVerifyAllowlistedImages`: Enforces credential checks for user workloads while exempting essential infrastructure images on an allowlist. -+ -Before this update, multi-tenant {product-title} clusters had a security vulnerability where the kubelet did not re-verify credentials for cached images. If one tenant pulled a private image, another tenant could deploy a pod by using that same cache without providing image pull secrets. To mitigate this previously, administrators relied on unsupported configurations. However, these workarounds caused cluster instability, risked control plane failures during registry outages, and blocked crucial cluster upgrades. -+ -[NOTE] -==== -Do not use the `NeverVerifyPreloadedImages` policy when the default `KubeletEnsureSecretPulledImages` feature gate is active, as the policy might not function as expected. Use the `NeverVerifyAllowlistedImages` policy instead. -==== -+ -For more information, see xref:../machine_configuration/machine-configs-custom.adoc#create-a-kubeletconfig-crd-to-edit-kubelet-parameters_machine-configs-custom[Creating a KubeletConfig CRD to edit kubelet parameters]. - -CPU resource enforcement is now enabled by default:: -+ -With this update, the `system-reserved-compressible` parameter is enabled for all clusters that do not use the reserved CPU feature. This addresses previous issues where the system reserved CPU exceeded the desired limit. This default can be overridden by configuring the `systemReservedCPU: ""` parameter in a kubelet configuration. -+ -For more information, see xref:../nodes/nodes/nodes-nodes-resources-configuring.adoc#system-reserved-compressible_nodes-nodes-resources-configuring[How {product-title} enforces system-reserved CPU]. - -Mount an OCI image into a pod:: -+ -With this update, you can use an image volume to mount an Open Container Initiative (OCI)-compliant artifact directly into a pod. OCI artifacts enable users to store and distribute arbitrary files and metadata using OCI compliant container registries. -+ -For more information, see xref:../nodes/pods/nodes-pods-image-volume.adoc#nodes-pods-image-volume[Mounting OCI images and artifacts into a pod]. - -Configurable storage locations for CRI-O artifacts:: -+ -With this update, you can create additional, non-default artifact storage locations in CRI-O that your pods can pull from. By using storage locations for the CRI-O container engine other than the default for OCI artifacts, complete container images, or container image layers, you can reduce application startup time and make your applications run more efficiently. -+ -For more information, see xref:../nodes/nodes/nodes-nodes-additional-crio-storage.adoc#nodes-nodes-additional-crio-storage[Additional CRI-O storage locations for faster container startup]. - -Project-scoped image pull secrets for mirrored registries (Technology Preview):: -+ -With this update, you can pull images from mirrored registries by using project-scoped pull secrets as a technology preview feature. Before this update, you needed to use node-level secrets when pulling from a mirrored registry because the kublet does not recognize the mirror configuration, which is configured at the container-runtime level. -+ -For more information, see xref:../openshift_images/image-configuration.adoc#images-configuration-registry-mirror-project-secret_image-configuration[Configuring project-scoped image pull secrets for mirrored registries]. - -Partitionable devices are now supported with dynamic resource allocation (Technology Preview):: -+ -With this update, the dynamic resource allocation feature supports partitioning physical hardware into smaller, logical instances, such as Multi-Instance GPUs, based on workload demands. With this technology preview feature, you can safely and efficiently share GPUs across multiple pods. -+ -For more information, see xref:../nodes/pods/nodes-pods-allocate-dra.adoc#nodes-pods-allocate-dra[Allocating GPUs to pods by using DRA]. - -[id="ocp-release-notes-openshift-cli_{context}"] -== OpenShift CLI (oc) - -Digest-based image pinning for the oc-mirror v2 plugin:: -+ -With this update, the oc-mirror v2 plugin pins Operator catalog images by their digest in your `ImageSetConfiguration` custom resource. Pinning by digest ensures that you always deploy the same Operator catalog image, regardless of any later changes to the upstream tags. For more information, see xref:../disconnected/about-installing-oc-mirror-v2.adoc#oc-mirror-workflows-partially-disconnected-v2_about-installing-oc-mirror-v2[Mirroring images for a disconnected installation by using the oc-mirror plugin v2]. - -Configuration of custom target repositories and tags for additional images by using the oc-mirror v2 plugin:: -+ -With this update, when using the oc-mirror v2 plugin, you can provide custom destination repository path and tag for specific images. By using the new `targetRepo` and `targetTag` fields within the `additionalImages` section of your `ImageSetConfiguration` custom resource, you can specify the target repository and tag for an image in your target mirror registry. For more information, see xref:../disconnected/about-installing-oc-mirror-v2.adoc#oc-mirror-imageset-config-parameters-v2_about-installing-oc-mirror-v2[ImageSet configuration parameters for oc-mirror plugin v2]. - -Availability of the `oc mirror list` command in oc-mirror v2 plugin:: -+ -With this update, you can use the list support feature with the oc-mirror v2 plugin. You can run the `oc mirror list` command to explore available platform and Operator content, including their specific versions, from remote and local registries. For more information, see xref:../disconnected/about-installing-oc-mirror-v2.adoc#oc-mirror-building-image-set-config-v2_about-installing-oc-mirror-v2[Creating the image set configuration]. // [id="ocp-release-notes-operator-development_{context}"] // == Operator development @@ -527,56 +151,7 @@ Detailed information. [id="ocp-release-notes-post-install-configuration_{context}"] == Postinstallation configuration -Support for the PCI addresses of NICs in `BareMetalHost` hardware data:: -+ -With this release, the Peripheral Component Interconnect (PCI) address for each network interface controller (NIC) is available in two separate custom resources (CRs). The PCI address is located in the `status.hardware.nics[]` section of the `BareMetalHost` CR and in the `spec.hardware.nics[]` section of the `HardwareData` CR. While these are separate resources, the values in the `pciAddress` fields, for example `0000:00:03.0`, are identical. -+ -For more information, see xref:../installing/installing_bare_metal/bare-metal-postinstallation-configuration.adoc#bmo-about-the-baremetalhost-resource_bare-metal-postinstallation-configuration[About the BareMetalHost resource] and xref:../installing/installing_bare_metal/bare-metal-postinstallation-configuration.adoc#the-baremetalhost-status[The BareMetalHost status]. - -{bmaas-first} is generally available:: -+ -With this update, {bmaas-first}, formerly known as Bare Metal as a Service (BMaaS), is generally available. You can provision and manage bare-metal hosts by using the Metal^3^ API and the Bare Metal Operator (BMO). These hosts, external to the {product-title} cluster, can run workloads that might not be suitable for containerization or virtualization, such as legacy applications or applications that require direct hardware access. For more information, see xref:../installing/installing_bare_metal/bare-metal-using-bare-metal-as-a-service.adoc#bare-metal-using-bare-metal-as-a-service[Using {bmaas-first}]. - -Expanding bare-metal clusters using OCI images and {bmaas-first} (Technology Preview):: -+ -With this update, you can expand your bare-metal cluster using {bmaas-first} with images from an OCI registry as a Technology Preview feature. You can use images from public OCI registries or from the built-in cluster registry. For more information, see xref:../installing/installing_bare_metal/bare-metal-using-bare-metal-as-a-service.adoc[Using Red Hat Bare Metal as a Service for OpenShift]. - -Adding an ARM node to an x86 bare metal cluster:: -+ -With this update, you can add ARM nodes to bare metal clusters with x86 control planes using PXE or virtual media. You can expand your cluster by creating a `BareMetalHost` object with the `aarch64` architecture, and then scaling the machine set to deploy the new machine. -+ -For more information, see xref:../installing/installing_bare_metal/bare-metal-expanding-the-cluster.adoc#preparing-the-bare-metal-node_bare-metal-expanding[Preparing the bare metal node]. - -[id="ocp-release-notes-rhcos_{context}"] -== {op-system-first} - -{op-system} uses {op-system-base} 9.8:: -+ -With this update, {op-system} uses {op-system-base-full} 9.8 packages in {product-title} 4.22. These packages ensure that your {product-title} instances receive the latest fixes, features, enhancements, hardware support, and driver updates. - -{op-system} 10.2 support (Technology Preview):: -+ -With this update, you can configure your cluster to use {op-system} 10.2 as a Technology Preview feature. You can update the nodes in an existing non-production test cluster or install a new non-production test cluster. For more information, see xref:../machine_configuration/mco-image-streams.adoc#mco-image-streams[Setting the RHCOS version in a cluster]. - -Ignition update to version 2.26.1:: -+ -With this update, the Ignition utility is updated to version 2.26.1. - -Butane update to version 0.26.0:: -+ -With this update, the Butane utility is updated to version 0.26.0. - -Afterburn update to version 5.10.0:: -+ -With this update, the Afterburn utility is updated to version 5.10.0. - -coreos-installer update to version 0.26.0:: -+ -With this update, the coreos-installer utility is updated to version 0.26.0. -Support for the numad package:: -+ -With this update, the numad package is supported. numad is an automatic NUMA affinity management daemon. It monitors NUMA topology and resource usage within a system that dynamically improves NUMA resource allocation, management, and system performance. //https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/overview-of-performance-monitoring-options //// @@ -598,13 +173,6 @@ FCoE is a protocol to transmit Fibre Channel frames over Ethernet networks. For [id="ocp-release-notes-scale-and-perform_{context}"] == Scalability and performance -// TELCODOCS-2272 -NUMA-aware scheduler supports clusters with up to 500 nodes:: -+ -With this release, you can scale the NUMA-aware secondary scheduler to support clusters with up to 500 nodes. The scheduler defaults to a `Burstable` quality of service (QoS) profile, which reduces baseline resource consumption while allowing the scheduler to scale up during peak loads. -+ -For more information, see xref:../scalability_and_performance/cnf-numa-aware-scheduling.adoc#cnf-topology-aware-scheduler-scalability_numa-aware[Topology-aware scheduler scalability]. - // [id="ocp-release-notes-support-sigstore_{context}"] // == Support for sigstore bring your own PKI (BYOPKI) image validation @@ -616,106 +184,17 @@ Item description:: Detailed information. //// -CRI-O ExecCPUAffinity protects low-latency workloads from exec process interruption:: -+ -With this release, you can protect latency-sensitive workloads from performance degradation caused by `oc exec` and shell processes. When you apply a `PerformanceProfile`, the CRI-O `ExecCPUAffinity` feature automatically pins exec processes to a designated CPU within the container's allocated set, preventing them from running on your workload CPUs. This feature is enabled by default for `Guaranteed` QoS pods with whole-integer CPU requests and requires no additional configuration. You can disable it per profile by adding the `performance.openshift.io/exec-cpu-affinity: "disable"` annotation to the `PerformanceProfile`. -+ -For more information, see xref:../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-exec-cpu-affinity_cnf-tuning-low-latency-nodes-with-perf-profile[How `ExecCPUAffinity` prevents latency spikes from exec operations]. - [id="ocp-release-notes-support_{context}"] == Support -Custom image configuration for the {support-log-gather}:: -+ -With this update, you can collect diagnostic data by using custom images in the {support-log-gather}. By pointing the `spec.imageStreamRef` field to an approved `ImageStream` tag, you can override the default image. The cluster administrators are responsible for creating and maintaining the list of allowed custom images by managing `ImageStream` resources in the Operator namespace. Each custom image requires its own `MustGather` custom resource and a service account with permissions to access the `ImageStream`. For more information, see xref:../support/gathering-cluster-data.adoc#support-log-gather-config-cli_gathering-cluster-data[Configuring a {support-log-gather} instance]. [id="ocp-release-notes-storage_{context}"] == Storage -[id="release-notes-storage-images-snapshot-class_{context}"] -=== New VolumeSnapshotClass csi-gce-pd-vsc-images is generally available -By default, you cannot restore more than six volumes per snapshot per hour. So in Kubevirt environments, you normally cannot create more than six VMs per hour from a "golden image" (templates saved as snapshots). - -For Google Cloud Platform (GCP) persistent disk (PD) storage Container Storage Interface (CSI), there is now a non-default `VolumeSnapshotClass`, named `csi-gce-pd-vsc-images`, that uses the `snapshot-type: images` parameter. When using KubeVirt, it allows you to overcome the six VMs per hour restriction, so that you can create VMs from "golden images". - -This feature is generally available in {product-title} 4.22. - -For more information, see xref:../storage/container_storage_interface/persistent-storage-csi-snapshots.adoc#volume-snapshot-crds[Volume snapshots CRD: VolumeSnapshotClass]. - -[id="release-notes-storage-hyperdisk-balanced-ha-support_{context}"] -=== Support for Hyperdisk Balanced High Availability volumes is generally available -{product-title} 4.22 introduces support for Hyperdisk Balanced High Availability volumes as generally available. - -Hyperdisk Balanced High Availability volumes are useful for: - -* Protecting your applications from a zonal outage by synchronously replicating data across two zones in the same region -* When you require write access to the same volume in multiple zones - -For more information, see xref:../storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc#persistent-storage-csi-gcp-hyperdisk-ha-overview_persistent-storage-csi-gcp-pd[Hyperdisk-balanced high availability disks overview]. - -[id="release-notes-storage-lso-symlinks_{context}"] -=== Local Storage Operator symlinks management is generally available -To prevent storage breakage during {product-title} upgrades, {product-title} 4.22 provides a mechanism, the `LocalVolumeDeviceLink` Custom Resource Definition, to detect, alert, and remap broken symlinks without manual node-level intervention. - -The Local Storage Operator (LSO) traditionally creates persistent volumes (PVs) based on `/dev/disk/by-id/` paths, following the assumption that they are stable. However, Linux kernel updates, firmware updates, or `udev` rule changes can cause these supposedly stable names to change or disappear. - -Administrators have the following notification and correction options to deal with symlink disruptions: - -* Monitoring: (default) If the current and preferred path do not match, an alert occurs, but no changes occur to the current path. - -* Use existing path: Alerts are silenced and LSO uses the existing path. - -* Recreate symlinks: Symlinks are recreated to point to the new, updated device path. - -For more information, see xref:../storage/persistent_storage_local/persistent-storage-local.adoc#local-storage-symlinks-top-level_persistent-storage-local[Local Storage Operator symlinks management]. - -[id="release-notes-storage-mutable-csi-node-allocatable-property_{context}"] -=== Mutable CSI node allocatable property is generally available -This feature allows for dynamically updating the maximum number of storage volumes a node can handle. Without this feature, volume limits are essentially immutable when a node first joins the cluster. If the environment changes—for example, if you attach a new network interface (ENI) that shares a hardware "slot" with your storage—OpenShift Container Platform does not recognize it has fewer slots available for disks, leading to pods becoming stuck. - -This feature is only supported on AWS Elastic Block Storage (EBS). - -Mutable CSI node allocatable property was introduced in {product-title} 4.21 as a Technical Preview feature. In {product-title} 4.22, it is supported as generally available. - -[id="release-notes-storage-secrets-store-csi-driver-operator_{context}"] -=== Updated release of the Secrets Store CSI Driver Operator -The Secrets Store CSI Driver Operator version v4.22 is now based on the upstream version v1.5.6 release of secrets-store-csi-driver. {product-title} 4.22 enables Secrets Store CSI Driver on {ibm-z-name}. - -[id="release-notes-storage-sovereign-cloud_{context}"] -=== European Sovereign Cloud (EUSC) region (Technology Preview) -European Sovereign Cloud (EUSC) region acts as a "digital fortress" built within a specific country’s borders. Sovereign Clouds are specifically designed to meet strict legal, jurisdictional, and security requirements of a particular nation or entity. - -In the context of storage, EUSC ensures that all data, including primary storage, backups, and the resulting metadata, resides physically within the specific nation’s borders and remains exclusively under its legal jurisdiction. - -For {product-title} 4.22, only AWS Elastic Block Storage supports EUSC. AWS Elastic File Storage (EFS) is not supported. - -EUSC is supported as a Technology Preview feature. - -For more information about EUSC, see xref:../storage/container_storage_interface/persistent-storage-csi-ebs.adoc#support-for-european-sovereign-cloud-eusc-region[Support for European Sovereign Cloud (EUSC) region]. - - [id="ocp-release-notes-web-console_{context}"] == Web console -Support for integrated OCI chart interaction:: -+ -The {product-title} web console now fully supports browsing, inspecting, and installing Open Container Initiative (OCI)-based Helm charts directly from configured repositories to provide functional parity with traditional HTTP(S) Helm charts. This enhancement removes the previous discovery-only limitation, enabling users to interact with and deploy OCI-based charts seamlessly within the console's repository views. -+ -For more information, see xref:../applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.adoc#configuring-custom-helm-chart-repositories[Configuring custom Helm chart repositories]. - -Azure Resource Group field for operator installations on Azure WIF clusters:: -+ -The operator installation page now includes a *Resource Group* field for operators who have the `token-auth-azure` annotation enabled on Azure Workload Identity Federation (WIF) clusters. As a result, operators who require an Azure resource group value, such as `ODF` (NooBaa), can complete their setup without manual workarounds. - -Install Helm charts from a direct URL:: -+ -In the web console, you can now install a Helm chart directly from a URL, without first adding the chart to a Helm chart repository or the console catalog. Both `oci://` and `https://` URLs are supported. -+ -[WARNING] -==== -Installing a Helm chart from a direct URL bypasses the validation checks provided by the developer catalog. Install charts only from URLs you trust, because unverified charts can introduce security risks to your cluster. When possible, use charts from the developer catalog or a configured Helm repository instead. -==== // Instructions: Add entries in the following format: diff --git a/modules/rn-ocp-release-notes-notable-changes.adoc b/modules/rn-ocp-release-notes-notable-changes.adoc index b824b935bec..05e5e4cc559 100644 --- a/modules/rn-ocp-release-notes-notable-changes.adoc +++ b/modules/rn-ocp-release-notes-notable-changes.adoc @@ -2,29 +2,11 @@ [id="rn-ocp-release-notes-notable-changes_{context}"] = Notable technical changes +[role="_abstract"] This section includes several technical changes for {product-title} {product-version}. // Instructions: Add entries in the following format: // Item description:: // + -// Detailed information. - -Platform components and Operators now use dedicated service accounts:: -+ -Most {product-title} platform components and Operators have been updated to use dedicated service accounts instead of the `default` service account. This change follows the principle of least privilege, simplifies security audits, and reduces the risk of accidental permission elevation by ensuring that platform identities are isolated from user workloads. -+ -The following dynamic tools continue to use the `default` service account to ensure operational efficiency: -+ --- -* `oc debug`: Uses the `default` service account to avoid the performance overhead of creating and removing unique service accounts for short-lived troubleshooting sessions. -* `oc adm must-gather`: Uses the `default` service account to collect diagnostic data across the cluster without requiring extensive manual RBAC modifications. --- -+ -For more information, see xref:../authentication/using-service-accounts-in-applications.adoc#default-service-accounts-and-roles_using-service-accounts[Default project service accounts and roles]. - -Unused Cluster API Operator image removed from release image:: -With this update, the {product-title} release image no longer includes the `cluster-api-operator` image. -As a result, you can no longer pull this image from the release image manually. -If you mirror the release image, you can delete this image from your mirror. -(link:https://redhat.atlassian.net/browse/OCPBUGS-61949[OCPBUGS-61949]) +// Detailed information. \ No newline at end of file diff --git a/modules/rn-ocp-release-notes-removed-features.adoc b/modules/rn-ocp-release-notes-removed-features.adoc index a0c910248bc..fa602d44c18 100644 --- a/modules/rn-ocp-release-notes-removed-features.adoc +++ b/modules/rn-ocp-release-notes-removed-features.adoc @@ -2,10 +2,5 @@ [id="rn-ocp-release-notes-removed-features_{context}"] = Removed features +[role="abstract"] This section includes removed features for {product-title} {product-version}. - -Deprecation and Removal of Dynamic Accelerator Slicer (DAS):: -+ -The Dynamic Accelerator Slicer (DAS) Operator was introduced to allow dynamic GPU partitioning in {product-title} until the Dynamic Resource Allocation (DRA) partitionable device feature is available. With the DRA feature available as a technology preview feature in {product-title} {product-version}, the DAS Operator has been deprecated and removed. -+ -For more information on DRA, see xref:../nodes/pods/nodes-pods-allocate-dra.adoc#nodes-pods-allocate-dra[Allocating GPUs to pods by using DRA]. diff --git a/release_notes/ocp-5-0-release-notes.adoc b/release_notes/ocp-5-0-release-notes.adoc new file mode 100644 index 00000000000..cf316c37090 --- /dev/null +++ b/release_notes/ocp-5-0-release-notes.adoc @@ -0,0 +1,47 @@ +:_mod-docs-content-type: ASSEMBLY +[id="ocp-5-0-release-notes"] += {product-title} {product-version} release notes +include::_attributes/common-attributes.adoc[] +:context: release-notes + +toc::[] + +[role="_abstract"] +Red{nbsp}Hat {product-title} provides developers and IT organizations with a hybrid cloud application platform for deploying both new and existing applications on secure, scalable resources with minimal configuration and management. {product-title} supports a wide selection of programming languages and frameworks, such as Java, JavaScript, Python, Ruby, and PHP. + +Built on {op-system-base-full} and Kubernetes, {product-title} provides a more secure and scalable multitenant operating system for today's enterprise-class applications, while delivering integrated application runtimes and libraries. {product-title} enables organizations to meet security, privacy, compliance, and governance requirements. + + +// About this release +include::modules/rn-ocp-about-this-release.adoc[leveloffset=+1] + +// {product-title} layered and dependent component support and compatibility +include::modules/rn-ocp-5-0-add-on-support-status.adoc[leveloffset=+1] + +// New features and enhancements +include::modules/rn-ocp-release-notes-new-features.adoc[leveloffset=+1] + +// Notable technical changes +include::modules/rn-ocp-release-notes-notable-changes.adoc[leveloffset=+1] + +// Deprecated and removed tables +include::modules/rn-ocp-release-notes-deprecated-removed-tables.adoc[leveloffset=+1] + +// Deprecated features +include::modules/rn-ocp-release-notes-deprecated-features.adoc[leveloffset=+1] + +// Removed features +include::modules/rn-ocp-release-notes-removed-features.adoc[leveloffset=+1] + +// Fixed issues +include::modules/rn-ocp-release-notes-fixed-issues.adoc[leveloffset=+1] + +// Technology Preview features status +include::modules/rn-ocp-release-notes-technology-preview.adoc[leveloffset=+1] + +// Known issues +include::modules/rn-ocp-release-notes-known-issues.adoc[leveloffset=+1] + +// Asynchronous errata updates +include::modules/rn-ocp-release-notes-async-errata-updates.adoc[leveloffset=+1] +