Goal

OLM v1 is going to delete CRDs shipped with the operator when extension's custom resource (the equivalent of the subscription CR in OLMv0) is removed.
See: https://operator-framework.github.io/operator-controller/tutorials/uninstall-extension/
OLM v0 is/was not doing that.
On CNV side, we are shipping by default with an option named BlockUninstallIfWorkloadsExist that is potentially conflicting blocking the removal of the operator CRs when VMs/DVs are there. Blocking the removal of a CR, will also block the removal of its CRD (see: https://github.com/kubernetes/kubernetes/issues/93392 ).
Let's understand and verify the impact on CNV removal with/without VMs (we are likely going to end with a zombie extension that is flagged for deletion but stuck in the middle).

User Stories

• As a cluster admin managing CNV with OLMv1, I want to be able to uninstall CNV without getting stuck and being able to re-install it in the future
• As a cluster admin managing CNV with OLMv1, I want to be able to uninstall CNV without permanently losing my VMs/DVs (to be evaluated!)

Non-Requirements

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

Notes

• On OLM v0 there was some front-end support (on the console) for operands removal, it was optional and we are opting out when BlockUninstallIfWorkloadsExist is set (the default)
• Upstream KubeVirt is providing only two uninstall strategies: RemoveWorkloads (to cascading delete VMs) and BlockUninstallIfWorkloadsExist (to block the removal of the CR for the kubevirt operator). Can we eventually think about introducing a new OrphanExistingWorkloads strategy to let the CNV operators go but preserving customers data for a future reinstall? (Can we adopt orphan resources on reinstall? what's the impact of a version skew/mismatch on resource adoption?)