-
Notifications
You must be signed in to change notification settings - Fork 1.4k
⚠️ Add v1beta2 API for ExtensionConfig #12197
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
base: main
Are you sure you want to change the base?
⚠️ Add v1beta2 API for ExtensionConfig #12197
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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 looks mostly like a copy/paste of the existing types and updating to the v1beta2 conditions. I left a couple of comments about API things I noticed but I'm not expecting those to be fixed here.
Are there known changes we want to make for v1beta2 for this API?
|
||
// ClientConfig contains the information to make a client | ||
// connection with an Extension server. | ||
type ClientConfig struct { |
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.
ClientConfig is required but does not have any required fields within it, so I could just created something with
clientConfig: {}
What would that mean? Is that valid? Should this actually be optional/have a required field/have a MinProperties
?
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.
As long as this is the only potential change (?), we could consider doing it here. Otherwise we should add it to:
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 lets track it and tackle separately. We could probably do a more thorough API review of these types to be honest
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.
+1 to make a thorough API review
In this case, exactly one of url
or service
must be specified so clientConfig cannot be nil
3cb61c4
to
95f2916
Compare
/lgtm |
LGTM label has been added. Git tree hash: 2ebc5a11324105549987e1c506689a8a6ff7ea54
|
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.
Great to see ExtensionConfig making progress, thanks!
only one nit from my side
// ExtensionConfigV1Beta1DeprecatedStatus groups all the status fields that are deprecated and will be removed when support for v1beta1 will be dropped. | ||
// See https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20240916-improve-status-in-CAPI-resources.md for more context. | ||
type ExtensionConfigV1Beta1DeprecatedStatus struct { | ||
// conditions defines current service state of the Machine. |
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.
// conditions defines current service state of the Machine. | |
// conditions defines current service state of the ExtensionConfig. |
New changes are detected. LGTM label has been removed. |
@chrischdi: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
What this PR does / why we need it:
Adds v1beta2 ExtensionConfig
Keeps using v1beta1 conditions for v1alpha1
Keeps lifecyclehooks on v1alpha1
Part of:
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 #
/area runtime-sdk