RFE: no supported Day 2 path to change load balancer type on an already-installed vSphere/baremetal cluster

Summary

There is no supported way to change a cluster's load balancer type (OpenShiftManagedDefault vs UserManaged) after installation, on vSphere or bare metal IPI. This blocks any Day 2 scenario that requires moving to a UserManaged load balancer on an already-installed cluster, including recovering from a control plane migration that moves nodes to a non-adjacent network.

What was tested

Confirmed directly against a live cluster's API, not just by reading docs:

• oc explain infrastructure.spec.platformSpec.vsphere.loadBalancer returns field "loadBalancer" does not exist. Same result for infrastructure.spec.platformSpec.baremetal.loadBalancer. Neither platform exposes a spec-level field for this.
• loadBalancer.type only exists under status.platformStatus.<platform>, a status field populated once at install time.
• A direct, privileged patch to the status subresource is rejected by API-level validation:

oc patch infrastructure cluster --subresource=status --type=merge \
  -p '{"status":{"platformStatus":{"vsphere":{"loadBalancer":{"type":"UserManaged"}}}}}'

The Infrastructure "cluster" is invalid: status.platformStatus.vsphere.loadBalancer.type: Invalid value: "UserManaged": type is immutable once set

This is enforced by a CEL validation rule in the CRD itself. There is no way around it through the Kubernetes API, at any privilege level.

Why this matters (concrete scenario)

Under openshift/vcf-migration-operator#109, migrating control plane nodes to a destination network that is not Layer 2 adjacent to the source causes a full cluster outage under the default load balancer, because VRRP-based VIP failover cannot cross a subnet boundary. The documented and only mitigation is to use a UserManaged load balancer. But because of the immutability described here, that mitigation is only available to a customer who happened to choose UserManaged at original install time, months or years before anyone knew a cross-vCenter migration would be needed. For the overwhelming majority of real vSphere/bare metal IPI customers (installed with the default load balancer, which is the out-of-the-box choice), there is currently no way to become eligible for this mitigation without a full cluster reinstall.

This is not specific to the migration operator. It blocks any future feature or Day 2 procedure that would need the same load-balancer-type transition on an already-installed cluster.

Recommendation

A supported Day 2 procedure to migrate an installed vSphere or bare metal cluster from OpenShiftManagedDefault to UserManaged load balancer type (and, ideally, the reverse) should be considered as its own feature. This would need to cover, at minimum:

• A schema change to allow this transition through the API in a controlled, one-directional way, rather than a blanket immutability rule
• Removing the in-cluster keepalived/haproxy static pods once the customer's external load balancer is confirmed reachable
• Updating each node's local coredns override for api/api-int/*.apps, which currently hardcodes the original virtual IP address independent of any external DNS changes the customer makes, confirmed live: even after standing up a working external load balancer and repointing external DNS, cluster nodes continued resolving api-int to the original virtual IP address via their own local coredns pod, unaffected by the external DNS change

Environment

• OCP 5.0.0-rc.1, vSphere IPI
• Confirmed the same result on infrastructure.spec.platformSpec.baremetal, so this is not vSphere-specific

Filed from hackathon testing under OCPSTRAT-2677.

Start by reproducing the oc explain infrastructure and status-subresource patch behavior described in the issue, then inspect the Infrastructure CRD's immutable CEL validation. Trace the existing keepalived/haproxy static pods and node-local coredns overrides. Done means a supported, validated Day 2 transition for vSphere and bare metal, including safe cleanup and DNS behavior.