Road to v1, CDI betav1 api

[Alexander Wels]

Hi,

As discussed during the KubeVirt summit, I would like to bring up the current dependency of KubeVirt on the CDI v1alpha1 api. In CDI right now we have to duplicate any new fields in both alpha and beta apis in order to satisfy KubeVirt using  the alpha version.

A while ago I made a PR to replace alpha with beta, but it got rejected on concerns about what would happen on an upgrade of kubevirt where we would potentially have an old virt-launcher depending on an alpha api datavolume. I don't think that would be an issue because once we get to the virt-launcher stage we are only dealing with PVCs and the CDI api is no longer involved.

Let's formulate a plan on how we can update KubeVirt to use the CDI beta api, and guarantee a smooth upgrade process.

Alexander

[Roman Mohr]

On Wed, Feb 10, 2021 at 10:59 PM Alexander Wels <aw...@redhat.com> wrote:

Hi,

As discussed during the KubeVirt summit, I would like to bring up the current dependency of KubeVirt on the CDI v1alpha1 api. In CDI right now we have to duplicate any new fields in both alpha and beta apis in order to satisfy KubeVirt using  the alpha version.

A while ago I made a PR to replace alpha with beta, but it got rejected on concerns about what would happen on an upgrade of kubevirt where we would potentially have an old virt-launcher depending on an alpha api datavolume. I don't think that would be an issue because once we get to the virt-launcher stage we are only dealing with PVCs and the CDI api is no longer involved.

Are you referencing https://github.com/kubevirt/kubevirt/pull/4164 ? I did not find any reference to this point. What I do see is that the concern is that kubevirt would just stop working with an older CDI if the CDI installation is too old.

I tend to say that your PR does the right thing, but we should probably just ensure that we waited long enough that we feel comfortable to say to someone who runs into problems here: "Hey this installation of CDI is X months old, you should have definitely updated it in the meantime".

We are probably a little bit weak in defining backward-compatibility periods and describing "supported" update flows: Like if you update CDI and KubeVirt from a 1.5 year old installation, you have  to either install intermediate versions or update CDI first.

What do you think?

Best Regards,

Roman

 

Let's formulate a plan on how we can update KubeVirt to use the CDI beta api, and guarantee a smooth upgrade process.

Alexander

--
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/CAKDnqXYERFwNPns2JPHwJmM5DLpkO-a230TjvL9do5gKFpf1Cw%40mail.gmail.com.

[Alexander Wels]

On Thu, Feb 11, 2021 at 8:27 AM Roman Mohr <rm...@redhat.com> wrote:

On Wed, Feb 10, 2021 at 10:59 PM Alexander Wels <aw...@redhat.com> wrote:

Hi,

As discussed during the KubeVirt summit, I would like to bring up the current dependency of KubeVirt on the CDI v1alpha1 api. In CDI right now we have to duplicate any new fields in both alpha and beta apis in order to satisfy KubeVirt using  the alpha version.

A while ago I made a PR to replace alpha with beta, but it got rejected on concerns about what would happen on an upgrade of kubevirt where we would potentially have an old virt-launcher depending on an alpha api datavolume. I don't think that would be an issue because once we get to the virt-launcher stage we are only dealing with PVCs and the CDI api is no longer involved.

Are you referencing https://github.com/kubevirt/kubevirt/pull/4164 ? I did not find any reference to this point. What I do see is that the concern is that kubevirt would just stop working with an older CDI if the CDI installation is too old.

Yes that is the PR: This is the comment I am referring to: https://github.com/kubevirt/kubevirt/pull/4164#issuecomment-692327569

 

I tend to say that your PR does the right thing, but we should probably just ensure that we waited long enough that we feel comfortable to say to someone who runs into problems here: "Hey this installation of CDI is X months old, you should have definitely updated it in the meantime".

We are probably a little bit weak in defining backward-compatibility periods and describing "supported" update flows: Like if you update CDI and KubeVirt from a 1.5 year old installation, you have  to either install intermediate versions or update CDI first.

What do you think?

Agreed, we should define a matrix where we say if you run KubeVirt version X, you need a minumum of CDI version Y to have it supported.