Let's imagine, that I have v1alpha1 version of my CRD and it works fine. After some time of developing, I have to migrate to another struct of CRD and v1beta1 version, which has some new required fields, which are not present in the previous spec of apiVersion. So now, I have to support both versions of my CRD, until all users manually migrate to a new one. So, how to handle this case with two working v1alpha1 and v1beta1 versions properly?
What do I have now:
I've read several related issues: 1, 2, 3, 4. And they generally describe ways of how to softly migrate from one version to another using ConversionWebhook and //+kubebuilder:storageversion annotation.
I tried to implement ConvertTo(dstRaw conversion.Hub) function, which raises error in case if automatic migration to a new apiVersion is not possible, and got an error conversion webhook for ... connect: connection refused while trying to kubectl get
I tried to implement two controllers for two apiVersion's, but eventually came to an error CRD for smth has no storage version, which tells me that there cannot be two controllers for different versions of a resource at the same time.
So, in short, my question is: How to handle case, when it's impossible to migrate to a new apiVersion due to breaking changes in spec?
Or am I doing something wrong and ideologically this shouldn't happen?
What did you do?
Migrating to a new apiVersion of CRD.
What did you expect to see?
Support both apiVersion's of CRD.
What did you see instead? Under which circumstances?
For now, I have no idea of how to add to a spec of a new apiVersion CRD new required fields.
Type of question
Question
Let's imagine, that I have
v1alpha1
version of my CRD and it works fine. After some time of developing, I have to migrate to another struct of CRD andv1beta1
version, which has some new required fields, which are not present in the previous spec of apiVersion. So now, I have to support both versions of my CRD, until all users manually migrate to a new one. So, how to handle this case with two workingv1alpha1
andv1beta1
versions properly? What do I have now:ConversionWebhook
and//+kubebuilder:storageversion
annotation.ConvertTo(dstRaw conversion.Hub)
function, which raises error in case if automatic migration to a newapiVersion
is not possible, and got an errorconversion webhook for ... connect: connection refused
while trying tokubectl get
apiVersion
's, but eventually came to an errorCRD for smth has no storage version
, which tells me that there cannot be two controllers for different versions of a resource at the same time.So, in short, my question is: How to handle case, when it's impossible to migrate to a new
apiVersion
due to breaking changes in spec?Or am I doing something wrong and ideologically this shouldn't happen?
What did you do?
Migrating to a new apiVersion of CRD.
What did you expect to see?
Support both
apiVersion
's of CRD.What did you see instead? Under which circumstances?
For now, I have no idea of how to add to a spec of a new
apiVersion
CRD new required fields.Environment
Operator type: /language go
Kubernetes cluster type:
"vanilla"
$ operator-sdk version
operator-sdk version: "v1.27.0", commit: "5cbdad9209332043b7c730856b6302edc8996faf", kubernetes version: "v1.25.0", go version: "go1.19.5", GOOS: "darwin", GOARCH: "arm64"
$ go version
(if language is Go)go version go1.21.6 darwin/arm64
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.3", GitCommit:"25b4e43193bcda6c7328a6d147b1fb73a33f1598", GitTreeState:"clean", BuildDate:"2023-06-14T09:47:38Z", GoVersion:"go1.20.5", Compiler:"gc", Platform:"darwin/arm64"} Kustomize Version: v5.0.1 Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.10", GitCommit:"0fa26aea1d5c21516b0d96fea95a77d8d429912e", GitTreeState:"clean", BuildDate:"2024-01-17T13:38:41Z", GoVersion:"go1.20.13", Compiler:"gc", Platform:"linux/amd64"}