openshift · tedaveryredhat · Aug 25, 2026
diff --git a/modules/rn-ocp-5-0-add-on-support-status.adoc 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].
diff --git a/modules/rn-ocp-release-notes-fixed-issues.adoc b/modules/rn-ocp-release-notes-fixed-issues.adoc
diff --git 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}.