VM Operator v1alpha2

[akutz]

This is a question about the release process for the CSI driver for vSphere. We would like to update it to use the VM Operator v1alpha2 API schema to reduce the cost associated with webhook conversion. However, will this mean the CSI driver for vSphere will need to detect the installed API schema and determine if it is safe to use v1a2? We would like to avoid having to put that burden on y'all, but it's also clear we need to update at some point. Thanks!

cc @bryanv @aruneshpa

[divyenpatel]

@adikul30 has the PR out for review - #2831

In this PR we are not checking if registered CR on the supervisor is v1a1 or v1a2.

There is a comment regarding conversion in the webhook - #2831 (comment) with that driver does not need to check API version.

[adikul30]

Hello @akutz, based on my conversation with @zyiyi11 - after an upgrade, the VMOP conversion webhook is supposed to convert VMs with v1a1 specs to v1a2 specs. That way any k8s clients using the VM spec post upgrade don't need to check the spec version and also don't need to have any fallback mechanism in the code to handle the older spec.

The PR has been put up with this understanding in mind. Does that sound correct?

[akutz]

Yes, conversion webhooks will handle this for you. However, for multiple reasons it is preferable to move to v1alpha2 sooner rather than later.

• Eventually support for v1alpha1 via conversion webhooks will be removed and no longer present on Supervisors. This won't happen for a while, but still, like any Kubernetes schema version, alpha versions are not meant to last forever.
• There is a lot of CPU time tied up in API conversion. The sooner we get folks to the latest version, the better it is for the entire Supervisor resource footprint.

The question @bryanv and I had was this -- if you do move to v1alpha2, will CSI also still need to support v1alpha1 in some cases? We are not sure how y'all handle releases and whether or not a new version of CSI could make its way onto an older version of Supervisor that does not have VM Op v1a2. Does that make sense?

[adikul30]

We are not sure how y'all handle releases and whether or not a new version of CSI could make its way onto an older version of Supervisor that does not have VM Op v1a2

CSI cuts a separate branch from ToT for new supervisor releases. For bug fixes or adding new k8s support on patch releases, we usually only cherry-pick required changes on top of that previous release's product branch.

[akutz]

In which case then yes, as soon as y'all are able to move to v1a2, then great. Again though, please do not consider it a blocker. It will help, but it's not a P0.

[adikul30]

Why isn't this a blocker right now? QE recently filed a bug from a main build where VirtualMachine was created with v1a2 spec and CSI logic failed to parse it correctly.

[bryanv]

It doesn't matter if the VM was created with v1a1 or v1a2. It matters when. The naming of those underlying network interface CR was changed because it couldn't handle multiple interfaces on the same network and v1a2 gained an interface Name field that is used to better identify the corresponding CR. It could change again. This has nothing to do with version conversion - CSI, CAPV, wcp, and other v1a1 consumers have all been unknowing using version conversion since VMOP switched to v1a2 a few months ago.