From ee5c722241b97acfce71c833bd071ee0bb1186ab Mon Sep 17 00:00:00 2001 From: Tami Love Date: Tue, 2 Jun 2026 00:19:42 -0400 Subject: [PATCH] add installer RNs for 4.22 --- .../rn-ocp-release-notes-fixed-issues.adoc | 20 +++++++++++++++++++ .../rn-ocp-release-notes-new-features.adoc | 4 ++++ 2 files changed, 24 insertions(+) diff --git a/modules/rn-ocp-release-notes-fixed-issues.adoc b/modules/rn-ocp-release-notes-fixed-issues.adoc index 8f9d3ce56111..935746eb2180 100644 --- a/modules/rn-ocp-release-notes-fixed-issues.adoc +++ b/modules/rn-ocp-release-notes-fixed-issues.adoc @@ -106,6 +106,26 @@ The following issues are fixed for this release: [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 diff --git a/modules/rn-ocp-release-notes-new-features.adoc b/modules/rn-ocp-release-notes-new-features.adoc index 89faacec3d65..3f88b314c458 100644 --- a/modules/rn-ocp-release-notes-new-features.adoc +++ b/modules/rn-ocp-release-notes-new-features.adoc @@ -172,6 +172,10 @@ 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...`.