[OSDOCS#18387]: Release Notes for 4.20.15

cicd/builds/triggering-builds-build-hooks.adoc

@@ -14,11 +14,22 @@ include::modules/builds-webhook-triggers.adoc[leveloffset=+2]
 
 include::modules/unauthenticated-users-system-webhook.adoc[leveloffset=+3]
 
+// Preventing cluster failure due to webhooks
+include::modules/preventing-cluster-webhook-failure.adoc[leveloffset=+3]
+
+// Recovering an unstable cluster due to admission webhooks
+include::modules/recover-unstable-cluster-webhooks.adoc[leveloffset=+3]
+
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../authentication/using-rbac.adoc#unauthenticated-users-cluster-role-bindings-concept_using-rbac[Cluster role bindings for unauthenticated groups]
 
+ifndef::openshift-rosa-hcp[]
+* xref:../../architecture/admission-plug-ins.adoc#admission-webhooks-about_admission-plug-ins[Webhook admission plugins]
+
+endif::openshift-rosa-hcp[]
+
 include::modules/builds-using-github-webhooks.adoc[leveloffset=+3]
 
 include::modules/builds-using-gitlab-webhooks.adoc[leveloffset=+3]

modules/monitoring-about-accessing-monitoring-web-service-apis.adoc

@@ -1,17 +1,13 @@
 // Module included in the following assemblies:
 //
-// * observability/monitoring/accessing-third-party-monitoring-apis.adoc
+// * observability/monitoring/accessing-metrics/accessing-monitoring-apis-by-using-the-cli.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="about-accessing-monitoring-web-service-apis_{context}"]
 = About accessing monitoring web service APIs
 
-You can directly access web service API endpoints from the command line for the following monitoring stack components:
-
-* Prometheus
-* Alertmanager
-* Thanos Ruler
-* Thanos Querier
+[role="_abstract"]
+To interact with the monitoring stack by using the command line, you can access web service API endpoints for Prometheus, Alertmanager, Thanos Ruler, and Thanos Querier. Direct API access requires bearer token authentication and the correct namespace permissions.
 
 [IMPORTANT]
 ====

modules/preventing-cluster-webhook-failure.adoc

@@ -0,0 +1,20 @@
+// Module included in the following assemblies:
+//
+// * builds/triggering-builds-build-hooks.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="third-party-cluster-webhook-failure_{context}"]
+= Prevent cluster failure due to webhooks
+
+[role="_abstract"]
+To prevent potential cluster failure and ensure pods can always start, you must configure third-party admission webhooks to exclude infrastructure namespaces. Implementing specific selectors and adopting a `ValidatingAdmissionPolicy` resource provides a more stable environment for cluster recovery and management.
+
+When possible, use a `ValidatingAdmissionPolicy` resource instead of an admission webhook. It does not require an external service, has no timeout limitations, and cannot cause cluster-wide failures.
+
+If you use admission webhooks take the following precautions:
+
+* Configure the webhook to exclude {product-title} and Kubernetes infrastructure namespaces.
+
+* Configure webhook timeouts to 10 seconds or less to provide a safety buffer for the system-enforced 13-second limit.
+
+* Set the `failurePolicy` value to `Ignore` for non-critical webhooks so that requests can proceed if the webhook is unavailable.

modules/recover-unstable-cluster-webhooks.adoc

@@ -0,0 +1,68 @@
+// Module included in the following assemblies:
+//
+// * builds/triggering-builds-build-hooks.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="third-party-cluster-webhook-failures_{context}"]
+= Recovering an unstable cluster due to admission webhooks
+
+[role="_abstract"]
+If a misconfigured admission webhook causes your cluster to fail, you must delete the webhook configuration to restore functionality.
+
+.Procedure
+
+. Back up the webhook configuration. Choose either `ValidatingWebhookConfiguration` or `MutatingWebhookConfiguration` for the `<webhook_configuration>` value.
++
+[source,terminal]
+----
+oc get <webhook_configuration> <webhook_name> -o yaml > webhook-backup.yaml
+----
+
+. Delete the webhook.
++
+[source,terminal]
+----
+oc delete <webhook_configuration> <webhook_name>
+----
+
+. Fix the webhook configuration to exclude infrastructure namespaces when you reapply it.
++
+.Example
+[source,yaml]
+----
+apiVersion: admissionregistration.k8s.io/v1
+kind: MutatingWebhookConfiguration
+metadata:
+  name: machine-api
+webhooks:
+  - name: default.machine.machine.openshift.io
+    rules:
+      - apiGroups: [""]
+        apiVersions: ["v1"]
+        operations: ["CREATE", "UPDATE"]
+        resources: ["pods"]
+        scope: "*"
+    clientConfig:
+      service:
+        namespace: machine-api-operator-webhook
+        name: openshift-machine-api
+        path: "/validate"
+    admissionReviewVersions: ["v1"]
+    sideEffects: None
+    timeoutSeconds: 5
+    namespaceSelector:
+      matchExpressions:
+        - key: kubernetes.io/metadata.name
+          operator: NotIn
+          values:
+            - openshift
+            - openshift-apiserver
+            - openshift-authentication
+            - openshift-monitoring
+            - kube-system
+            - kube-public
+            - kube-node-lease
+            - default
+----
++
+Where `kind` is the type of webhook configuration you are using. Valid values are `ValidatingWebhookConfiguration` or `MutatingWebhookConfiguration`.

modules/rn-async-errata.adoc

@@ -2,7 +2,6 @@
 //
 // * release_notes/ocp-4-20-release-notes.adoc
 
-
 :_mod-docs-content-type: CONCEPT
 [id="ocp-release-asynchronous-errata-updates_{context}"]
 = Asynchronous errata updates

modules/zstream-4-20-0.adoc

@@ -0,0 +1,27 @@
+// Module included in the following assemblies:
+//
+// * release_notes/ocp-4-20-release-notes.adoc
+
+//Update with relevant advisory information
+:_mod-docs-content-type: REFERENCE
+[id="ocp-4-20-0_{context}"]
+= RHSA-2025:9562 - {product-title} {product-version}.0 image release, bug fix, and security update advisory
+
+[role="_abstract"]
+Issued: 21 Oct 2025
+
+{product-title} release {product-version}.0, which includes security updates, 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-2025:9562[RHSA-2025:9562] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHEA-2025:4782[RHEA-2025:4782] 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.20.0 --pullspecs
+----
+
+[id="ocp-4-20-0-updating_{context}"]
+== Updating
+
+To update an {product-title} 4.20 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI].

modules/zstream-4-20-1.adoc

@@ -0,0 +1,69 @@
+// Module included in the following assemblies:
+//
+// * release_notes/ocp-4-20-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="ocp-4-20-1_{context}"]
+= RHSA-2025:19003 - {product-title} {product-version}.1 image release, bug fix, and security update advisory
+
+[role="_abstract"]
+Issued: 28 Oct 2025
+
+{product-title} release {product-version}.1, which includes security updates, 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-2025:19003[RHSA-2025:19003] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHEA-2025:19001[RHEA-2025:19001] 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.20.1 --pullspecs
+----
+
+[id="ocp-4-20-1-known-issues_{context}"]
+== Known issues
+
+This release contains the following known issues:
+
+* Starting with {product-title} 4.20, there is a decrease in the default maximum open files soft limit for containers. As a consequence, end users may experience application failures. To work around this problem, increase the container runtimes (CRI-O) ulimit configuration. (link:https://issues.redhat.com/browse/OCPBUGS-62095[OCPBUGS-62095])
+
+[id="ocp-4-20-1-fixed-issues_{context}"]
+== Fixed issues
+
+The following issues are fixed for this release:
+
+* Before this update, iDRAC10 hardware provisioning was failing due to an incorrect data type for the Dell Original Equipment Manufacturer (OEM) `Target` property and the use of an incorrect virtual media slot. As a result, users were unable to provision Dell iDRAC10 servers. With this release, the Dell iDRAC10 can be provisioned. (link:https://issues.redhat.com/browse/OCPBUGS-52427[OCPBUGS-52427])
+
+* Before this release, two identical copies of the same controller were updating the same certificate authority (CA) bundle in a `configmap` causing them to receive different metadata inputs, rewrite each other's changes, and create duplicate events. With this release, the controllers use optimistic updating and server-side apply to avoid update events and handle update conflicts. As a result, metadata updates no longer trigger duplicate events, and the expected metadata is set correctly. (link:https://issues.redhat.com/browse/OCPBUGS-55217[OCPBUGS-55217])
+
+* Before this update, when installing a cluster on {ibm-power-server-title} you could only specify a name for an existing Transit Gateway or virtual private cloud (VPC). As the uniqueness of names was not guaranteed, this could cause conflicts and installation failures. With this release, you can use Universally Unique Identifiers (UUIDs) for a Transit Gateway and VPC. By using unique identifiers, the installation program can unambiguously identify the correct Transit Gateway or VPC. This prevents the naming conflicts and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-59678[OCPBUGS-59678])
+
+* Before this update, the Cloud event proxy for the Precision Time Protocol (PTP) Operator incorrectly parsed BF3 Network Interface Card (NIC) names, causing the interface alias to be formatted incorrectly. As a consequence, the incorrect parsing caused end users to misinterpret cloud events. With this release, the Cloud event proxy has been updated to correctly parse BF3 NIC names in the PTP Operator. As a result, fix improves parsing of BF3 NIC names, ensuring correct event publication for the PTP Operator. (link:https://issues.redhat.com/browse/OCPBUGS-60466[OCPBUGS-60466])
+
+* Before this update, a pod with a secondary interface in an OVN-Kubernetes Localnet network (mapped to the br-ex bridge) could communicate with pods on the same node that used the default network for connectivity only if the Localnet IP addresses were within the same subnet as the host network. With this release, the localnet IP addresses can be drawn from any subnet; in this generalized case, an external router outside the cluster is expected to connect the localnet subnet to the host network. (link:https://issues.redhat.com/browse/OCPBUGS-61453[OCPBUGS-61453])
+
+* Before this update, the Precision Time Protocol (PTP) Operator wrongly parsed network interface controller (NIC) names. As a result, interface aliases were incorrectly formatted and this impacted identifying a PTP hardware clock (PHC) when using Mellaonox cards to send clock state events. With this release, the PTP now correctly parses the NIC names so that generated aliases align with Mellanox naming conventions. Mellanox cards can now accurately identify a PHC when sending clock state events.  (link:https://issues.redhat.com/browse/OCPBUGS-61581[OCPBUGS-61581])
+
+* Before this update, the `cluster in workload identity mode` warning was missing when only the `token-auth-azure` annotation was set, which could lead to misconfiguration. This update adds a check for the `token-auth-azure` annotation when showing the warning. As a result, clusters that use only Azure Workload Identity now show the “cluster in workload identity mode” warning as expected. (link:https://issues.redhat.com/browse/OCPBUGS-61861[OCPBUGS-61861])
+
+* Before this update, the YAML editor in the web console would default to indenting YAML files with 4 spaces. With this release, the default indentation has changed to 2 spaces to align with recommendations. (link:https://issues.redhat.com/browse/OCPBUGS-61990[OCPBUGS-61990])
+
+* Before this update, deploying hosted control planes in version 4.20 or later with user-supplied `ignition-server-serving-cert` and `ignition-server-ca-cert` secrets`, along with the `disable-pki-reconciliation annotation`, caused the system to remove the user supplied ignition secrets and the `ignition-server` pods to fail. With this release, the `ignition-server` secrets are preserved during reconciliation after removing the delete action for the `disable-pki-reconciliation` annotation ensuring ignition-server pods start. (link:https://issues.redhat.com/browse/OCPBUGS-62006[OCPBUGS-62006])
+
+* Before this update, if the `OVNKube-controller` on a node failed to process updates and configure its local OVN database, the `OVN-controller` could connect to this stale database. This caused the `OVN-controller` to consume outdated `EgressIP` configurations and send incorrect Gratuitous ARPs (GARPs) for an IP address that might have already moved to a different node. With this release, the `OVN-controller` is blocked from sending these GARPs during the time when the `OVNKube-controller` is not processing updates. As a result, network disruptions are prevented by ensuring GARPs are not sent based on stale database information. (link:https://issues.redhat.com/browse/OCPBUGS-62273[OCPBUGS-62273])
+
+* Before this update, upgrading a `ClusterExtension` could fail when unhandled Customer Resource Definition (CRD) changes produced a large JSON diff for the validation status. This diff often exceeded the Kubernetes 32 KB limit, causing the status update to fail and leaving users with no information about why the upgrade did not occur. With this release, the diff output is truncated and summarized for unhandled scenarios instead of including the full JSON diff. This ensures the status updates remain within size limits, allowing them to post successfully and provide users with clear, actionable error messages. (link:https://issues.redhat.com/browse/OCPBUGS-62722[OCPBUGS-62722])
+
+* Before this update, gRPC connection logs were set at a highly verbose log level. This generated an excessive number of messages, which caused the logs to overflow. With this release, the gRPC connection logs have been moved to the V(4) log level. Consequently, the logs no longer overflow, as these specific messages are now less verbose by default. (link:https://issues.redhat.com/browse/OCPBUGS-62844[OCPBUGS-62844])
+
+* Before this update, running `oc-mirror` without displaying its version caused delays in debugging, as the correct version with required fixes was not known. As a consequence, the user was unable to identify `oc-mirror` version, hindering efficient debugging. With this release, `oc-mirror` now displays its version in the output, aiding faster debugging and ensuring correct fix application. (link:https://issues.redhat.com/browse/OCPBUGS-62283[OCPBUGS-62283])
+
+* Before this update, a bug occurred when the `cluster-api-operator` kubeconfig controller tried to use a regenerated authentication token secret before the token value was fully populated. This caused users to experience recurring, transient reconciliation errors every 30 minutes, which briefly put the Operator into a degraded state. With this release, the controller now waits for the authentication token to be populated within the secret before proceeding, preventing the Operator from going into a degraded state and eliminates the recurring errors. (link:https://issues.redhat.com/browse/OCPBUGS-62755[OCPBUGS-62755])
+
+* Before this update, in {product-title} 4.19.9, the Cluster Version Operator (CVO) began requiring bearer token authentication in metrics requests. As a consequence, this broke the metrics scraper on hosted control plane clusters because their scrapers provided no client authentication. With this release, the CVO no longer requires client authentication for metrics requests in hosted control plane clusters. (link:https://issues.redhat.com/browse/OCPBUGS-62867[OCPBUGS-62867])
+
+* Before this update, during failover, the system's duplicate address detection (DAD) could incorrectly disable the Egress IPv6 address if it was briefly present on both nodes, breaking the connection. With this release, the Egress IPv6 is configured to skip the DAD check during failover, guaranteeing uninterrupted egress IPv6 traffic after an Egress IP address successfully moves to a different node and ensuring greater network stability. (link:https://issues.redhat.com/browse/OCPBUGS-62913[OCPBUGS-62913])
+
+[id="ocp-4-20-1-updating_{context}"]
+== Updating
+To update an {product-title} 4.20 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI].