I'd like to make a proposal to deprecate and eventually remove
`VirtualMachineInstancePreset` in favor of the recently renamed
instancetype API with the `VirtualMachineInstancetype` and
The following is taken from an early design document for instancetypes
(then flavors) written by dvossel that sets out some of the issues with
> ## Flavors vs VMI Presets Explained
> Early on in KubeVirt’s development we recognized the need for a
> mechanism to allow users to model reusable settings one time that can be
> automatically applied to multiple VMI specs. At the time we looked to
> the Kubernetes ecosystem to see what patterns already existed for this
> type of behavior. The closest thing we found was the PodPreset. In order
> to align with the larger ecosystem, we developed a
> VirtualMachineInstancePreset which closely resembles PodPresets.
> Since then, presets have proved both difficult to manage and incapable
> of expressing all the logic necessary to support emerging use cases. We
> weren’t the only ones who recognized this pattern is suboptimal at
> times. The Kubernetes ecosystem is deprecating PodPresets as well. Below
> are some of the primary issues encountered with VMI presets.
> * Namespace scoped
> No way to define VMI presets at a global level
> * Non deterministic behavior
> A VMI that results in merging multiple presets together can produce
> unexpected results.
> * Undetectable merging conflicts
> VMs which successfully started in the past are not guaranteed to be
> valid in the future if matching presets are altered.
> * Designed before VM/VMI api split
> Attempting to use presets with VMs might result in the VMI spec
> later being rejected due to validation errors because the presets
> are not applied to the vm.Spec.VMITemplate section. Presets are
> instead only applied at the point of starting the VM when the VMI is
> The Flavor API solves all of the points above.
> * Designed specifically for the VM API
> * Both globally and namespaced scoped
> * Deterministic behavior - only one flavor can be matched to a VM.
> * Merge conflicts are always immediately detected - Flavor to VM mapping
> is immutable after VM creation
I'm currently updating the flavor design proposal given the recent
rename and will include a version of the above for future reference.
The following draft PR sets out what I think is initially required to
start this process following the CRD versioning documentation in k8s:
Obviously a clear migration path for existing preset users will need to
exist before we ever remove it entirely in a future major release (v2
Anyway, comments and thoughts very much welcome here especially from any
active `VirtualMachineInstancePreset` users. I'll also be raising this
during the next community meeting.
Many thanks in advance,
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76