-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add ADR explaining removal of kubebuilder defaults #335
Conversation
3fd7b63
to
89228c4
Compare
Signed-off-by: Alexandr Demicev <alexandr.demicev@suse.com>
89228c4
to
32a9943
Compare
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.
This is just a question and not a blocker for merging the PR. Can this deprecation of default values cause an issue for users that have been using older versions of the provider? Let's say that a user provisions clusters via a GitOps tool (like Fleet) and they are missing some of the fields that no longer have a default value. Now they update CAPRKE2 to the new version that requires to set fields manually. Is it possible that this breaks their downstream cluster/s?
@salasberryfin Defaults are only evaluated on the first apply, then the applied data is stored in etcd, so all existing manifests should already have user defined values for these fields. |
Thanks @Danil-Grigorev. |
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Checklist: