Proposal to deprecate VirtualMachineInstancePreset

[Lee Yarwood]

Hello all,

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
`VirtualMachinePreference` CRDs.

The following is taken from an early design document for instancetypes
(then flavors) written by dvossel that sets out some of the issues with
Presets:

> ## 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
> created.
>
> 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:

Deprecate VirtualMachineInstnacePresets
https://github.com/kubevirt/kubevirt/pull/8069

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
etc).

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

[Lee Yarwood]

I've not seen any negative feedback about this proposal as yet so I've
made the PR ready to review. I'm still looking for feedback, positive or
negative so please do feel free to comment here or in the PR either way.

Regards,

[Stu Gott]

As the one who originally authored the VMI Preset API, I'll happily support this effort. The thing that's always bothered me about VMI Presets is that it feels backwards. Presets match VMs, not the other way around. Because of this, settings that aren't explicitly enumerated in a VMI's manifest will be applied. This feels like a "surprise the user" anti-pattern.

 

Regards,

--
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/20220802081432.2u7as6r6jpwh7cmh%40lyarwood-laptop.usersys.redhat.com.

[Lee Yarwood]

An aspect of this that has caused some back and fourth in the PR is how
long we need to wait before the eventual removal of the CRD from
KubeVirt [1]. I had originally suggested we would need to wait until a
`v2` version of the API is available as per the default k8s API
deprecation policy but this was questioned.

I think we are now in agreement within the comment thread that this is
unfortunately the only way forward for now but I wanted to raise this on
the ML for further input.

Apologies for not being present on the community call to discuss this
but I have an internal conflict with the meeting this week.

Cheers,

Lee

[1] https://github.com/kubevirt/kubevirt/pull/8069#discussion_r937779363

[Fabian Deutsch]

Looking at http://kubevirt.io/api-reference/main/definitions.html#_v1_virtualmachineinstancepreset then we see that it indeed is part of v1 (not v1alpha1 or beta1), thus yeah , looks like we have no choice.

WHile we need to keep it in the API, do we know approchaes that Kubernetes is taking to deperecated APIs liek this? Is the prior art for deprecating a stable API?

- fabian

 

Apologies for not being present on the community call to discuss this
but I have an internal conflict with the meeting this week.

Cheers,

Lee

[1] https://github.com/kubevirt/kubevirt/pull/8069#discussion_r937779363

--
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/20220817141256.ixiwwxmlczew3tye%40lyarwood-laptop.usersys.redhat.com.

[Lee Yarwood]

This did come up during the discussion and we couldn't find any prior
examples of v1 removals [1][2]. Autoscaling appears to be one of the few
APIs with both a v1 and v2 version but the former isn't deprecated yet
AFAICT.

[1] https://github.com/kubevirt/kubevirt/pull/8069#discussion_r945518139
[2] https://kubernetes.io/docs/reference/using-api/deprecation-guide/#removed-apis-by-release

[Fabian Deutsch]

IIUIC then there is at least an example of how to setup depreciation notices.

[Lee Yarwood]

On 22-08-22 16:20:17, Fabian Deutsch wrote:
> IIUIC then there is at least an example of how to setup depreciation
> notices.

Yeah indeed and the PR should be inline with this AFAIK.