Chapter 1. Hosted control planes release notes

Before this update, when a hosted cluster was upgraded to multiple versions over time, the version history in the HostedCluster resource sometimes exceeded 10 entries. However, the API had a strict validation limit of 10 items maximum for the version history field. As a consequence, users could not edit or update their HostedCluster resources when the version history exceeded 10 entries. Operations such as adding annotations (for example, for cluster size overrides) or performing maintenance tasks like resizing request serving nodes failed with a validation error: "status.version.history: Too many: 11: must have at most 10 items". This error prevented ROSA SREs from performing critical maintenance operations that might impact customer API access.

With this release, the maximum items validation constraint has been removed from the version history field in the HostedCluster API, allowing the history to grow beyond 10 entries without triggering validation errors. As a result, HostedCluster resources can now be edited and updated regardless of how many entries exist in the version history, so that administrators can perform necessary maintenance operations on clusters that have undergone multiple version upgrades. (OCPBUGS-58200)

Before this update, following a CLI refactoring, the MarkPersistentFlagRequired function stopped working correctly. The --name and --pull-secret flags, which are critical for cluster creation, were marked as required, but the validation was not being enforced. As a consequence, users could run the hypershift create cluster command without providing the required --name or --pull-secret flags, and the CLI would not immediately alert them that these required flags were missing. This could lead to misconfigured deployments and confusing error messages later in the process.

This release adds an explicit validation in the RawCreateOptions.Validate() function to check for the presence of the --name and --pull-secret flags, returning clear error messages when either flag is missing. Additionally, the default "example" value is removed from the name field to ensure proper validation. As a result, when users attempt to create a cluster without the required --name or --pull-secret flags, they now receive immediate, clear error messages indicating which required flag is missing (for example, "Error: --name is required" or "Error: --pull-secret is required"), preventing misconfigured deployments and improving the user experience. (OCPBUGS-37323)

Before this update, a variable shadowing bug in the GetSupportedOCPVersions() function caused the supportedVersions variable to be incorrectly assigned using := instead of =, creating a local variable that was immediately discarded rather than updating the intended outer scope variable. As a consequence, when users ran the hypershift version command with the HyperShift Operator deployed, the CLI would either display <unknown> for the Server Version or panic with a "nil pointer dereference" error, preventing users from verifying the deployed HyperShift Operator version.

This release corrects the variable assignment from supportedVersions := to supportedVersions = in the GetSupportedOCPVersions() function to properly assign the config map to the outer scope variable, ensuring the supported versions data is correctly populated. As a result, the hypershift version command now correctly displays the Server Version (for example, "Server Version: f001510b35842df352d1ab55d961be3fdc2dae32") when the HyperShift Operator is deployed, so that users can verify the running operator version and supported OpenShift Container Platform versions. (OCPBUGS-57316)

Before this update, the shared ingress controller did not handle the HostedCluster.Spec.KubeAPIServerDNSName field, so custom kube-apiserver DNS names were not added to the router configuration. As a consequence, traffic destined for the kube-apiserver on a hosted control plane that used a custom DNS name (via HostedCluster.Spec.KubeAPIServerDNSName) was not routed correctly, preventing the KubeAPIExternalName feature from working with platforms that use shared ingress.

This release adds handling for HostedCluster.Spec.KubeAPIServerDNSName in the shared ingress controller. When a hosted cluster specifies a custom kube-apiserver DNS name, the controller now automatically creates a route that directs traffic to the kube-apiserver service. As a result, traffic destined for custom kube-apiserver DNS names is now correctly routed by the shared ingress controller, enabling the KubeAPIExternalName feature to work on platforms that use shared ingress. (OCPBUGS-57790)

When a node pool is scaled down to 0 workers, the list of hosts in the console still shows nodes in a Ready state. You can verify the number of nodes in two ways:

If you created a hosted cluster in the same namespace as its managed cluster, detaching the managed hosted cluster deletes everything in the managed cluster namespace including the hosted cluster. The following situations can create a hosted cluster in the same namespace as its managed cluster: