-
Epic
-
Resolution: Done
-
Normal
-
None
-
ga-instancetype-controller-revision-upgrade
-
Product / Portfolio Work
-
False
-
-
False
-
-
Green
-
To Do
-
VIRTSTRAT-154 - GA and Instance Types by default
-
-
0% To Do, 0% In Progress, 100% Done
-
dev-ready, doc-ready, po-ready, qe-ready, ux-ready
-
Goal
VirtualMachines referencing instance types or preferences have ControllerRevisions created containing a point in time copy of the referenced resource. See the user guide for more on this:
https://kubevirt.io/user-guide/virtual_machines/instancetypes/#versioning
While this allows KubeVirt to always produce the same VirtualMachineInstance at run time regardless of changes to the original resource it does currently mean that KubeVirt has to support older versions of the instancetype.kubevirt.io CRDs for the lifetime of these VirtualMachines.
This epic proposes the introduction of two new controllers to virt-controller to migrate the stashed instancetype.kubevirt.io objects within these ControllerRevisions to their latest version, hopefully allowing support for older deprecated versions to be dropped from the codebase.
Motivation
In order to drop support for older deprecated versions of the instancetype.kubevirt.io API and CRDs we need to ensure the following conditions are met:
- All stored objects in etcd are migrated to the latest version
- All stashed objects in ControllerRevisions are migrated to the latest version
The former is taken care by KubeVirt's existing recommendation to use the kube-storage-version-migrator tool with KubeVirt >= v1.0.0 to handle the migration of stored objects from kubevirt.io/v1alpha3 to kubevirt.io/v1.
However without any way of migrating stashed instancetype.kubevirt.io objects within ControllerRevisions we can never drop support for older deprecated versions.
User Stories
- As a developer I want deprecated versions of instancetype.kubevirt.io to be eventually removed from KubeVirt, reducing the on-going maintenance effort required for future versions of KubeVirt.
- As a user I want my existing VirtualMachines and running VirtualMachineInstances to be unaffected by the migration and the eventual removal of older versions of instancetype.kubevirt.io.
- As a user I want my existing VirtualMachineSnapshots to be unaffected by the migration and the eventual removal of older versions of instancetype.kubevirt.io
Non-Requirements
- Currently a ControllerRevision is captured for each VirtualMachine and combination or instance type or preference. The deduplication of these ControllerRevisions is saved for follow up work but might be an additional step when migrating to a new ControllerRevision using labels to identify existing ControllerRevisions containing the same version and importantly generation of an object
Notes
- is documented by
-
CNV-31342 Doc: Upgraded environments automatically migrate instancetype ControllerRevisions
-
- Closed
-