Auto-resolved image import picks wrong RHCOS major stream (9 instead of 10)

Summary

When spec.image is left empty for automatic resolution (the documented default path), the operator resolves and imports RHCOS 9.x, even when the cluster's nodes are actually running RHCOS 10.x. Confirmed live: the operator resolved and attempted to import rhel-9.8/builds/9.8.20260428-0 while the test cluster's nodes reported Red Hat Enterprise Linux CoreOS 10.2.20260902-0.

Why this matters

OCP 5.0 supports two RHCOS major streams in the same release (dual-stream RHCOS 9/RHCOS 10 support, OCPSTRAT-1150). A customer letting the operator auto-import the destination template would get new control plane or worker nodes provisioned on a different major OS version than the rest of the cluster, silently, with no warning surfaced anywhere in the migration CR's status.

Root cause

The auto-resolve path uses stream-metadata-go against the coreos-bootimages ConfigMap but does not appear to check which RHCOS major stream the cluster's existing nodes are actually running. It defaults to resolving the historical/primary stream (RHCOS 9) regardless of what the cluster is currently on.

Recommendation

The auto-resolve path should detect the cluster's current active RHCOS stream, for example from existing node OS-image values or the relevant MachineConfigPool's configured stream, and resolve against that stream rather than defaulting to RHCOS 9.

Environment

• OCP 5.0.0-rc.1, nodes running RHCOS 10.2.20260902-0
• vcf-migration-operator dev-preview build, spec.image: {} (auto-resolve)

Filed from hackathon testing under OCPSTRAT-2677.

Start at the auto-resolve path that uses stream-metadata-go with the coreos-bootimages ConfigMap. Inspect how existing node OS-image values or the MachineConfigPool stream can identify the active RHCOS major version, then verify that spec.image: {} resolves to that stream instead of defaulting to RHCOS 9. Done means the imported image matches the cluster's active RHCOS major stream.