Release ahead of Kubernetes

[saschagrunert]

The main problem is that we vendor Kubernetes, requiring an updated go.mod which is just available after the final Kubernetes release. Therefore we usually lack days/weeks behind Kubernetes, which is not really acceptable from a packaging point of view, because Kubernetes deb/rpm packages have direct requirements on cri-tools.

Given that cri-tools v1.27.1 (latest) may not work 100% correctly with Kubernetes v1.28.0, I'm proposing to:

Release cri-tools before Kubernetes with vendoring the latest release candidate.

@kubernetes-sigs/cri-tools-maintainers thoughts on that? I think this makes things easier from a release flow perspective.

[haircommander]

is it possible to do a similar thing to cri-o and commit to a release timeline after kubernetes? or is even a day's lag or something unacceptable from the kubernetes packaging perspective?

[saschagrunert]

is it possible to do a similar thing to cri-o and commit to a release timeline after kubernetes?

Yes, that's indeed possible from my point of view.

[haircommander]

since cri-tools has fewer blocking changes than cri-o, we could commit to something short like a day or two?

[saschagrunert]

Hm, we release v1.28.0 on Aug 15 and the rc.1 on Aug 10th. So we can prepare the vendor change on Aug 11th and release cri-tools v1.28.0 right on Monday, Aug 14.

See: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.28

[afbjorklund]

This is making the compatibility "window" really really short, compared to how it used to be (1.19 forever).

It makes it even more important to install cri-tools with the kubernetes version, and not a global installation.

• Install cri-tools/cni-plugins with bootstrapper, and not with provisioner kubernetes/minikube#15460

• Update CRI and CNI installations to the ones used by default kubernetes kubernetes/minikube#15495

[afbjorklund]

Given that cri-tools v1.27.1 (latest) may not work 100% correctly with Kubernetes v1.28.0,

This sounds like the CRI API is broken. Changing the dependency would be a rather big change.

Kubernetes v1.27.0 had kubernetes-cni (>= 1.1.1), cri-tools (>= 1.25.0) with a much bigger skew.

Wouldn't it be enough to bump it to 1.27.0, and the release take the days or weeks that it needs?

[saschagrunert]

Given that cri-tools v1.27.1 (latest) may not work 100% correctly with Kubernetes v1.28.0,

This sounds like the CRI API is broken. Changing the dependency would be a rather big change.

It's not. If we assume we add new CRI fields in k8s v1.28.0, which may be required by CRI-O v1.28.0 as well, then a cri-tools v1.27.x is not able to provide the full client data set like a kubelet v1.28, so we cannot guarantee that it 100% works correctly if the runtime does not manually add upgrade paths. So it all depends on the runtime from my point of view.

[afbjorklund]

Stills sounds like a very tight coupling for an external project - but I will go with whatever the kubernetes release does...

Note that if you release cri-tools 1.28 now, there will be many 1.27 installations picking it up (since it is not pinned/held)

Then again, they are current using 1.26.0 (since there was no release for 1.27.0) - so maybe it's more of a recommendation

And soon, they will have different package repositories for different k8s versions - after the OBS introduction in KEP-1731

[saschagrunert]

I propose that we try it out for 1.28, especially since we can check the new OBS workflow this way. I'm going to propose a vendor update after v1.28.0-rc.1 has been cut: kubernetes/sig-release#2301

[saschagrunert]

Done