-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
KEP-3685: Move EndpointSlice Reconciler into Staging #3686
Conversation
akhilles
commented
Dec 12, 2022
- One-line PR description: Move EndpointSlice Reconciler into Staging
- Issue link: Move EndpointSlice Reconciler into Staging #3685
Welcome @akhilles! |
Hi @akhilles. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
/ok-to-test |
/cc This and #3649 should have some overlap since they're both proposing the moving of core code into staging |
/cc |
/lgtm just moving code around so can be easily imported 👍 |
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.
Thanks @akhilles! Mostly LGTM, just a few tiny nits.
keps/sig-network/3685-endpointslice-reconciler-to-staging/README.md
Outdated
Show resolved
Hide resolved
/cc |
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.
If rob is LGTM, I will approve
/approve
(assume `staging_root = staging/src/k8s.io/endpointslice`): | ||
- `pkg/controller/endpointslice/metrics => $staging_root/metrics` | ||
- `pkg/controller/endpointslice/topologycache => $staging_root/topologycache` | ||
- `pkg/controller/util/endpoint => $staging_root/util` |
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.
The cost of moving to staging is increased API durability and scrutiny. If we tell people it is OK to use, we are promising not to break them.
I'd like to use this process to see if there's a way NOT to have "util" packages. Looking at these, most of them should either be internal/...
or in the main staging repo directly, or in some properly-designed sub-pkg of this staging repo.
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.
Agreed, we should avoid the "util" package. It's explicitly called out in the coding conventions doc as well:
Avoid general utility packages. Packages called "util" are suspect.
A combination of copying small functions (+ making them private) and moving others into the main package seems reasonable to me. I'll cover this as part of the public API doc.
The following dependencies don’t have to be moved as there’s only one trivial | ||
function used from each: | ||
- `pkg/api/v1/pod` | ||
- `IsPodReady` function can be moved to `component-helpers` as it’s also |
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.
or just copied - copying a small function is not forbidden.
- `IsPodReady` function can be moved to `component-helpers` as it’s also | ||
used by `kubectl`. | ||
- `pkg/apis/core/v1/helper` | ||
- `IsServiceIPSet` function can be moved to staging or mirrored. |
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.
same
|
||
### Risks and Mitigations | ||
|
||
Users might expect compatibility to be maintained for the library’s public API. |
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.
We SAY this, but we also hold staging to a higher bar than k/k, so I will ask for a thorough re-examination of the API in terms of supportability and docs and quality.
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.
Ack, I'll draft a doc that evaluates the public API (+ any proposed changes) and send it out for review. I think a lot of the value of this KEP can be realized with a very small public API.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: akhilles, thockin 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 |