VEP #210: CentOS Stream 10 Support - Proposed Plan

[Lee Yarwood]

Hi all,

I've opened VEP #210 proposing a plan to transition KubeVirt from
CentOS Stream 9 to CentOS Stream 10. CentOS Stream 9 reaches end of
life on 2027-05-31, so we need to start this migration well ahead of
that date.

Some background: towards the end of the v1.8.0 cycle I was working on
CentOS Stream 10 based builds for the kubevirt-aie project. That work
involved getting the CS10 builder image, build system support, and CI
jobs in place upstream, which naturally led me to think about defining
a clear path for the broader CS10 transition in KubeVirt itself.

The VEP proposes a phased approach over three releases:

- **v1.9 (Alpha)**: Build and CI enablement. CS10 builder image,
optional build/e2e presubmit jobs, RPM dependency sync — all optional
and non-blocking. Much of this is already merged or in flight.

- **v1.10 (Beta)**: A representative subset of CS10 userspace e2e jobs
promoted to required, running alongside the existing CS9 jobs. CS9
userspace formally deprecated. To avoid overwhelming CI capacity (we
currently run ~20 required e2e presubmit jobs), only the core SIG
lanes on the latest k8s version would be required for CS10 during this
phase.

- **v1.11 (GA)**: CS10 becomes the sole userspace. CS9 build support
removed. kubevirtci providers also transition to CS10 at this point.

A key aspect of the proposal is that the **userspace** (container
images) and **host OS** (kubevirtci providers) transitions are kept
separate during the transition period. CS10 kubevirtci providers will
be available as optional jobs from v1.9 but won't become required
until v1.11, ensuring we can attribute any test failures clearly to
either userspace or host OS changes rather than both at once.

The VEP and tracking issue are here:

- VEP PR: https://github.com/kubevirt/enhancements/pull/237
- Tracking issue: https://github.com/kubevirt/enhancements/issues/210

Feedback and reviews welcome — especially from sig-compute, sig-ci,
and sig-buildsystem.

Cheers,

Lee

[Lee Yarwood]

Following downstream discussions, we simplified the suggested plan
into the following per-lane transition start in v1.9.0:

* v1.9 (Alpha): k8s-1.36 provider introduced on CS10 with CS10
userspace as the latest always_run lane. Older lanes (k8s-1.34,
k8s-1.35) remain on CS9. CS9 deprecated.
* v1.10 (Beta): k8s-1.37 introduced on CS10. k8s-1.34 (CS9) dropped.
Majority of always_run lanes on CS10.
* v1.11 (GA): k8s-1.35 (last CS9 lane) dropped. All lanes on CS10. CS9
build support removed.

Again feedback and reviews are welcome!

Cheers,

Lee