-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 API types for Runtime SDK ExtensionConfig #6383
✨ Add API types for Runtime SDK ExtensionConfig #6383
Conversation
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.
A few comments but only nits. Overall the relevant parts look good to me!
b7a80b2
to
ee3855a
Compare
ee3855a
to
785924f
Compare
Thx for the nice and quick work! :) Apart from the two discussion topics above, lgtm from my side. |
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 mentioned on slack, I've been working on API reviews for the last 6 months or so, and while I'm not sure you want to act on all of these right now, here's some initial API review style feedback for you to consider.
In general, this is pretty conformant, my main takeaway is I don't think we are leveraging the OpenAPI schema validation very much, and it would improve the UX if we were to do so.
In general, when reviewing, I also like to look at the comments authors are adding. We should consider the godocs as user facing (as they end up in kubectl explain
), so we should add as much detail there are possible, these are the general sort of questions I think about for the documentation part of the review:
- What is the purpose of this field? What does it allow them to achieve?
- How does setting this field interact with other fields or features?
- What are the limitations of this field?
- Does it have any maximum or minimum value?
- If it is a string value, are the values limited to a specific list or can it be free form, must it meet a certain regex?
- Limitations should be written out within the Godoc as well as added within kubebuilder tags. Kubebuilder tags are used for validation but are not included within any generated documentation.
See the validation docs for inspiration on more validations to apply.
- Is the field optional or required?
- When optional, what happens when the field is omitted?
// TimeoutSeconds defines the timeout duration for client calls to the ExtensionHandler. | ||
// +optional | ||
TimeoutSeconds *int32 `json:"timeoutSeconds,omitempty"` | ||
|
||
// FailurePolicy defines how failures in calls to the ExtensionHandler should be handled by a client. | ||
// +optional | ||
FailurePolicy *FailurePolicy `json:"failurePolicy,omitempty"` |
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.
Do either of these need to be pointers, is there a semantic difference between the zero go value and the nil value?
If there is, it's worth adding a comment to point this out, eg, when timeoutSeconds is set to 0, this disables the timeout <- I have no idea if that's true, just an example
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 these are pointers in line with the guidelines optional fields being pointers. Both of these will be defaulted if unset by users.
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'm not a strong opinion on this, but, upstream kube conventions say yes, these should be pointers, the CAPI conventions are loosely worded, Fields SHOULD be pointers if there is a good reason for it, for example:
, which to me reads as we would prefer them not to be pointers unless we have a good reason, based on that I would say these shouldn't be pointers but willing to yield as it's pretty minor
41bf904
to
29f4744
Compare
/retest |
Great job! |
3578085
to
2163a02
Compare
Squashed the commits. The one pending item from the comments I can see is if we want to keep the API version as |
It seems the API is on v1alpha1 as requested |
@ykakarap please fix webhook names |
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.
Found another v1beta1. Otherwise looks great and lgtm from my side
2163a02
to
ebeb2e2
Compare
@fabriziopandini All good from me, happy to proceed |
Signed-off-by: killianmuldoon <[email protected]>
ebeb2e2
to
9977653
Compare
Thx! /lgtm |
Thanks @JoelSpeed! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: killianmuldoon [email protected]
Implement the Extension Config API types outlined in the [Runtime SDK proposal] #6181.
This PR contains:
I'll sync any changes from here back into the proposal as this PR progresses.
Part of #6330
@sbueringer @fabriziopandini @vincepri @CecileRobertMichon @enxebre
(as this is a new API)
/area runtime-sdk
/kind feature