-
Notifications
You must be signed in to change notification settings - Fork 693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump CRD versions to v1beta1 #1782
Conversation
If we don't retain the v1alpha1 definitions, would it be possible to deploy the new version on top of an existing cluster without breaking anything? I can't seem to be able to apply the new CRDs without deleting the old ones first ( Also, should we consider implementing conversion to support a smoother upgrade flow? |
I think conversion would require a webhook server which is currently removed in master due to #1723 But it is definitely something we would like to do once it is restored. As to having multiple versions of the API: Can we try that and see if keeping |
No.
Yes. In the current state it will be a breaking change that implies a downtime.
Yes, I'm going to try this to avoid the breaking. |
As the schema has changed between v1alpha1 and v1beta1, I don't think we can have both versions referenced in the latest CRDs without implementing conversion. I tried with: versions:
- name: v1beta1
served: true
storage: true
- name: v1alpha1
served: false
storage: false And this workflow:
Then the operator is failing with the following errors:
Even if it's not our goal for now, I tried to update the
|
Would it help if instead of renaming we would keep the alpha versions around? |
Ok I played around with this a bit here pebrc@76fddfc and it looks like if we keep the original code around and fix the CRD generation (which was not running and broken) we can have both versions. But:
Also:
|
Well done!
The description fields can be truncated or removed using - $(CONTROLLER_GEN) crd paths="./pkg/apis/..." output:crd:artifacts:config=config/crds
+ $(CONTROLLER_GEN) crd:maxDescLen=100 paths="./pkg/apis/..." output:crd:artifacts:config=config/crds |
I used |
@@ -102,8 +102,7 @@ func (k *Kibana) SetAssociationConf(assocConf *commonv1alpha1.AssociationConf) { | |||
k.assocConf = assocConf | |||
} | |||
|
|||
// +genclient | |||
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | |||
// +kubebuilder:object:root=true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch
assocConf *commonv1alpha1.AssociationConf | ||
Spec KibanaSpec `json:"spec,omitempty"` | ||
Status KibanaStatus `json:"status,omitempty"` | ||
assocConf *commonv1alpha1.AssociationConf `json:"-"` //nolint:govet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we prefer to keep this hidden (that was the behaviour in 0.9).
Just to be clear since the v1beta1 types are essentially just a copy and paste of the v1alpha1 types, and they need to be that way to be compatible between versions: if we make any type changes in the future we need to make sure we change both the v1alpha1 and v1beta1 types, correct? Until we have a conversion webhook that is. |
No, if we make any type changes in the future, we need to create a new version (e.g. v1beta2 or v1). |
Also, we use our controller-version to prevent the latest operator (1.0.0-beta1) to handle previous custom resources (0.9), to overcome the fact that we have no conversion webhook. |
const ControllerVersionAnnotation = "common.k8s.elastic.co/controller-version" | ||
const ( | ||
ControllerVersionAnnotation = "common.k8s.elastic.co/controller-version" | ||
MinCompatibleControllerVersion = "0.10.0-SNAPSHOT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These names are confusing to me at least, just going by the names it's not clear why we would need both the last incompatible version and the minimum compatible version. Going by how they're used I think it's because we're using "last incompatible" to mean the version before we started adding the annotation, but it might be worth finding more descriptive names and/or adding explanatory comments on why these exist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm fine with MinCompatibleControllerVersion
.
How about we change LastIncompatibleControllerVersion to:
UnknownControllerVersion = "UNKNOWN" // may match resources created with ECK-0.8.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will that work? I think it needs to be a parseable version for later versions of the controller to know they shouldn't do anything with it when it does a version comparison, but definitely possible I'm misunderstanding
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, indeed! Then maybe:
UnknownControllerVersion = "0.0.0-UNKNOWN" // may match resources created with ECK-0.8.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I tested the alpha -> beta migration locally, everything seems to behave as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
A note to other reviewers: make sure you are on controller-gen 0.2.1, 0.2.0 has some surprising behavior
This should also close out #1770 |
Glad we are finally here. Thank you for your feedbacks. |
|
This commit bumps the version of the CRDS from version v1alpha1 to version v1betav1:
pkg/apis/*/v1alpha1
inpkg/apis/*/v1beta1
. Only differences exists for the ElasticsearchStatus (some fields have been removed since the 0.9)v1alpha1
are replaced byv1betav1
inpkg/
,config/
,test/
anddocs/*.asciidoc
trivialVersions=true
for now, CRD multi-versions support with schema changes #1823)apm
shortname for the APM ServerResolves #1140.