OSDOCS-20108:Update the z-stream RNs for 4.21.20

modules/zstream-4-21-20.adoc

@@ -0,0 +1,58 @@
+// Module included in the following assemblies:
+//
+// * release_notes/ocp-4-21-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="zstream-4-21-20_{context}"]
+= RHSA-2026:25187 - {product-title} {product-version}.20 fixed issues advisory
+
+Issued: 16 June 2026
+
+[role="_abstract"]
+{product-title} release {product-version}.20 is now available. The list of fixed issues that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2026:25187[RHSA-2026:25187] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2026:25185[RHBA-2026:25185] advisory.
+
+Space precluded documenting all of the container images for this release in the advisory.
+
+You can view the container images in this release by running the following command:
+
+[source,terminal]
+----
+$ oc adm release info 4.21.20 --pullspecs
+----
+
+[id="zstream-4-21-20-fixed-issues_{context}"]
+== Fixed issues
+
+* Before this update, pagination controls were not present at mobile resolutions because PatternFly expected both top and bottom pagination controls to be used.  With this release, pagination controls are present regardless of the mobile resolution. (link:https://redhat.atlassian.net/browse/OCPBUGS-84967[OCPBUGS-84967])
+
+* Before this update, the manila container storage interface (CSI) driver node plugin might have crashed on startup if the Network File System (NFS) CSI plugin socket was not yet available, This issue might have occurred, for example, after a node reboot. With this release, the manila CSI node DaemonSet waits for the NFS plugin socket to be ready before starting the driver, which prevents crash loops due to transient startup ordering. (link:https://redhat.atlassian.net/browse/OCPBUGS-85572[OCPBUGS-85572])
+
+* 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-85674[OCPBUGS-85674])
+
+* Before this update, a race condition occurred between network namespace management and the optional container mount namespace segregation in the rare instance when software on the host that was not within the {product-title} cluster created network namespaces. As a consequence, pods became stuck and could not restart. With this release, the race condition is solved by initializing the network namespace infrastructure before the container mount namespace. (link:https://issues.redhat.com/browse/OCPBUGS-86003[OCPBUGS-86003])
+
+* 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 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 update, 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-86027[OCPBUGS-86027])
+
+* Before this update, users without any projects received a `Restricted access` error message when they navigated to certain resource list pages (for example, the *Pods*, *PodDisruptionBudgets*, *RoleBindings*, *VolumeSnapshots*, and *Helm* pages). With this release, these pages correctly display an empty state instead of a misleading `403` error. (link:https://issues.redhat.com/browse/OCPBUGS-86314[OCPBUGS-86314])
+
+* Before this update, when you navigated to the resource detail pages for Shipwright components (`Build`, `BuildRun`, `BuildStrategy`, or `ClusterBuildStrategy`) with the builds for the {product-title} Operator installed, the console crashed with React error `#310`. With this release, the component rendering logic is corrected. As a result, Shipwright detail pages load successfully without crashing. (link:https://issues.redhat.com/browse/OCPBUGS-86427[OCPBUGS-86427])
+
+* Before this update, the Hosted Cluster Config Operator (HCCO) globalps and resources controllers did not have watches on the control-plane namespace pull secret. When you updated the Secret data referenced by the `HostedCluster.spec.pullSecret` parameter in-place (without changing the Secret name), the controllers had no way to immediately detect the change. As a consequence, on {aws-first} and {azure-first} clusters that used Replace upgrade type `NodePools`, in-place pull secret updates were not promptly propagated to the guest cluster. The `kube-system/original-pull-secret` and `openshift-config/pull-secret` secrets in the guest cluster reconciled only on the next periodic sync cycle, which caused a significant delay before updated registry credentials became available to the hosted cluster workloads. With this release, control-plane namespace pull-secret watches are added to the globalps and resources HCCO controllers so that they are notified immediately when the pull secret data changes in the control plane namespace. As a result, in-place updates to the pull secret referenced by the `HostedCluster.spec.pullSecret` parameter promptly propagate to `openshift-config/pull-secret`, `kube-system/original-pull-secret`, and the kubelet `config.json` parameter in the guest cluster through the Global Pull Secret DaemonSet, without requiring a `NodePool` rollout or the need to wait for a periodic resync.  (link:https://issues.redhat.com/browse/OCPBUGS-86477[OCPBUGS-86477]
+
+* Before this update, the `MachineSet` object scale sub-resource lacked a valid selector, which prevented autoscalers like HPA and KEDA from scaling the `MachineSet` object. As a consequence, autoscalers requiring a selector failed. With this release, the `MachineSet` object exposes an active label selector on the scale sub-resource, which enables scaling using autoscalers like HPA and KEDA that require the label selector to be populated. (link:https://issues.redhat.com/browse/OCPBUGS-86493[OCPBUGS-86493])
+
+* Before this update, the `python3-perf` RPM package was incorrectly pinned to an old version. As a result, the RPM package was being flagged by security scanners for including more than 400 outstanding CVEs because the `python-3-perf` RPM package was built from the kernel RPM package. With this release, the pinning issue is resolved. As a result, the scanning result will be clean. (link:https://issues.redhat.com/browse/OCPBUGS-86513[OCPBUGS-86513])
+
+* Before this update, when a user applied a `MachineConfig` parameter to install extensions, the Machine Config Operator (MCO) did not validate that all packages were installed. As a consequence, extension installation appeared to be successful, but packages were missing. With this release, the MCO validates after the node reboot that all packages associated with your desired extension were successfully installed before reporting a successful update. As a result, if one of more package is not present, the node, and subsequently the associated MachineConfigPool, will degrade. (link:https://issues.redhat.com/browse/OCPBUGS-86576[OCPBUGS-86576])
+
+* Before this update, the macOS Option key was treated as a Meta key instead of a compose key in the pod terminal. As a consequence, characters that rely on Option key combinations, such as `@`, `{`, `}`, `|`, `\`, and `~`, could not be entered. With this release, the terminal correctly identifies macOS, so the Option key functions as a compose key as expected.
+(link:https://issues.redhat.com/browse/OCPBUGS-86581[OCPBUGS-86581])
+
+* 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 release, the Operator schedules a retry of the status update until it succeeds, retrying approximately every 30 seconds. As a result, the stuck degraded status is temporary and resolves automatically during the next retry. (link:https://issues.redhat.com/browse/OCPBUGS-86809[OCPBUGS-86809])
+
+* 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-87002[OCPBUGS-87002])
+
+[id="zstream-4-21-20-updating_{context}"]
+== Updating
+
+To update an {product-title} 4.21 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI].

release_notes/ocp-4-21-release-notes.adoc

@@ -44,6 +44,9 @@ include::modules/rn-ocp-release-notes-known-issues.adoc[leveloffset=+1]
 // Asynchronous errata updates
 include::modules/rn-async-errata.adoc[leveloffset=+1]
 
+// 4.21.20 RNs and updating
+include::modules/zstream-4-21-18.adoc[leveloffset=+2]
+
 // 4.21.18 RNs and updating
 include::modules/zstream-4-21-18.adoc[leveloffset=+2]