Replies: 1 comment
-
Worth considering how kube-storage-version-migrator moving in-tree for k8s 1.30 could facilitate this workflow, refs kubernetes/enhancements#4192 and kubernetes/kubernetes#123344 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
With #2745 complete, GRPCRoute has met the criteria for graduation to standard channel in the v1.1 release. That means that it's going to be the first API to test our updated versioning policy that essentially skips beta.
It likely does not make sense to carry over any notion of the v1alpha2 version of this API to standard channel, so that would mean we'd end up with the following:
All of that should work reasonably well in most cases. Here's what that means for users upgrading to v1.1 CRDs:
As you can tell, upgrades from "experimental" to "standard" are always risky/unsafe because you're moving from an API with more things to an API with less things. In this case, it would actually be impossible to upgrade v1.0 Experimental GRPCRoute directly to v1.1 Standard GRPCRoute. That's because you'd be trying to upgrade to a CRD that had no awareness of the storage version that you were using for GRPCRoute (given that v1.1 standard likely doesn't include alpha API versions).
There are some possible workarounds here that would enable the migration path from experimental to standard. Some examples include:
This is likely a lot of thought for an upgrade path that probably won't be that common, but just wanted to get a conversation started around this because it's a fairly complex area and it will be our first time supporting this specific form of transition.
Beta Was this translation helpful? Give feedback.
All reactions