patch crd status.storedVersions if it has deprecated/unknown values #14
Conversation
Signed-off-by: Mikhail Scherba <mikhail.scherba@flant.com>
| crVersions = append(crVersions, version.Name) | ||
| } | ||
|
|
||
| if !slices.Equal(crVersions, existCRD.Status.StoredVersions) { |
There was a problem hiding this comment.
Honestly, I'm confused with this.
It works nice if we have storedVersion: ["v1", "v1alpha1", "v1alpha2"] and versions: ["v1"]. Then the field will be syncronized
But we have the other case (kubectl get crd nodegroups.deckhouse.io -o yaml)
In the quite fresh cluster it has:
kubectl get crd nodegroups.deckhouse.io -o json | jq .spec.versions.[].name
"v1alpha1"
"v1alpha2"
"v1"
but
kubectl get crd nodegroups.deckhouse.io -o json | jq .status.storedVersions[]
"v1"
So, the field will be syncronized and will show invalid stored versions
There was a problem hiding this comment.
so the question is if we want to have all spec.versions items in storedVersions or not. What if we add to storedVersions only the versions with the storage: true attribute?
There was a problem hiding this comment.
I recall a discussion about removing discontinued versions from storedVersions in context of the webhook handler being overutilized.
Considering the fact that a CRD's
status.storedVersionslist must not have entries missing in the.spec.versionspart of the CRD, otherwise, ais invalid: status.storedVersions[2]: Invalid value: "v1beta": must appear in spec.versionserror is thrown when applying a new version of the CRD containing a smaller subset of verions in.spec.versions, which is typical when discontinuing older versions of the CRD, it makes sense to compare and alignstoredVersionsvalues against the new set of.spec.versionsbefore updating the CRD.Originally, it was advised to update
storedVersionsas part of an error-handling process, but the text of the error is a matter of change between k8s versions, which makes it trickier to catch.