kubevirt
Deprecate VirtualMachineInstnacePresets
What this PR does / why we need it:
VirtualMachineInstancePresets are based on the PodPresets k8s resource and API that injected data into pods at creation time. However this API never graduated from alpha and was removed in 1.20 [1]. While useful there are some issues with the implementation that have resulted in alternative approaches such as VirtualMachineInstanceTypes and VirtualMachinePreferences being made available within KubeVirt.
As per the CRD versioning docs this change updates the generated CRD definition of VirtualMachineInstancePreset marking the currently available versions of v1 and v1alpha3 as deprecated.
[1] https://github.com/kubernetes/kubernetes/pull/94090 [2] https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#version-deprecation
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
The VirtualMachineInstancePreset resource has been deprecated ahead of removal in a future release. Users should instead use the VirtualMachineInstanceType and VirtualMachinePreference resources to encapsulate any shared resource or preferences characertistics shared by their VirtualMachines.
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
I'm not sure if we should also provide a warning if presets are referenced by a VirtualMachine and/or later applied to a VirtualMachineInstance?
Leaving this as draft until I've raised it on the ML and community meeting.
So with the removal of VMIPreset, is there a replacement API to template VMI objects? Or will templating only be supported for VMs i.e. VirtualMachineFlavors
So with the removal of VMIPreset, is there a replacement API to template VMI objects? Or will templating only be supported for VMs i.e. VirtualMachineFlavors
Only with VMs through VirtualMachineInstancetypes and VirtualMachinePreferences. I've been back and fourth on this with @davidvossel and others in another PR with the outcome being that the VMI usecase wasn't strong enough to warrant also supporting the application to VMIs directly. I'd be interested to hear if you disagree with this tbh.
Yet to see any negative feedback regarding this proposal so I'm marking this as ready for review now.
Obviously this doesn't close the door on further discussion so please do let me know if there are any issues with this!
@lyarwood when do you plan to release KubeVirt v0.56.0?
I'm not involved with the release process but I will note v0.56.0-rc.0 was just cut yesterday. That said this PR is just introducing the deprecation and not the removal of VirtualMachineInstancePresets so it shouldn't matter which release this eventually gets into.
That said this PR is just introducing the deprecation and not the removal of VirtualMachineInstancePresets so it shouldn't matter which release this eventually gets into.
That matters for the company I work for, since we are KubeVirt distributors we want to keep with KubeVirt up to date. Once v0.56 (or any release that includes the change) is out we should as well switch to the new API before. I will get the info on the slack channel. Thanks
That said this PR is just introducing the deprecation and not the removal of VirtualMachineInstancePresets so it shouldn't matter which release this eventually gets into.
That matters for the company I work for, since we are KubeVirt distributors we want to keep with KubeVirt up to date. Once v0.56 (or any release that includes the change) is out we should as well switch to the new API before. I will get the info on the slack channel. Thanks
Understood, it's unlikely to land in v0.56.0 with the rc already cut and the actual deprecation period is likely to be long for this as full removal will require a major version change to >= v2 of the API AFAICT.
Understood, it's unlikely to land in
v0.56.0with the rc already cut and the actual deprecation period is likely to be long for this as full removal will require a major version change to >=v2of the API AFAICT.
We did not formalize that, but there is an informal agreement that we probably want to follow the 1 year deprecation period of k8s, without requiring an API bump. Either way, @mfranczy I think/hope you should have enough time even if it lands soon.
The deprecation makes sense. It was kind of abandoned already since k8s decided to deprecate their presets and your replacements are pretty great.
/lgtm
waiting for other maintaintainers before approving.
@lyarwood: The label(s) area/instancetype cannot be applied, because the repository doesn't have them.
In response to this:
/area instancetype
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: davidvossel
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [davidvossel]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.
/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.
@lyarwood: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| pull-kubevirt-fossa | 0b69b7486e1b32cb75c3a3c1bdd07182885205d6 | link | false | /test pull-kubevirt-fossa |
| pull-kubevirt-e2e-kind-1.22-sriov | 0b69b7486e1b32cb75c3a3c1bdd07182885205d6 | link | unknown | /test pull-kubevirt-e2e-kind-1.22-sriov |
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.
/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.