Goal

Build CNV 4.18.z from a downstream fork of KubeVirt, which has upstream-incompatible backports

User Stories

• As CNV Product Manager, I would like to introduce a feature which is not currently available upstream into CNV 4.18.z, in order to satisfy urgent customer demand.
• As a CNV developer I would like to have a downstream git fork of KubeVirt, possibly under the openshift github org, where I can introduce downstream-only PRs into stable branches.
  • I would like these PRs to be rebased periodically on top of the upstream content
  • When I propose a new PR, I would like to receive an immediate feedback that the PR builds and passes sanely
  • When the PRs are rebased, I would like to receive an immediate feedback that the PR builds and passes sanely
  • As a container owner, I would like to configure CPaaS to build from the downstream fork if I choose so.

Non-Requirements

• List of things not included in this epic, to alleviate any doubt raised during the grooming process.

Notes

• Red Hat in general, and OpenShift Virtualization in particular, are staunch believers in the Upstream First principle. We are aware of the huge cost of each downstream-only PR and recommend against them. Features and APIs must first be proposed and accepted into KubeVirt upstream main branch before we consider a downstream-only backport.