-
Notifications
You must be signed in to change notification settings - Fork 1.5k
KEP-5328: Node Capabilities #5347
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: master
Are you sure you want to change the base?
Conversation
Welcome @pravk03! |
Hi @pravk03. 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-sigs/prow repository. |
59e7e54
to
4719180
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.
@dom4ha @sanposhiho @macsko - FYI
4c11e06
to
9254f9b
Compare
/cc @tallclair @yujuhong |
9254f9b
to
f8291a4
Compare
/sig scheduling |
Can we have any examples listed that will justify this. Right now the KEP suggests to use it for FG-related capabilities, while not giving a good examples where it would be non-FG related. |
419d78a
to
5fb093d
Compare
The scheduling part looks good for alpha |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: macsko, pravk03 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 |
The While this is still in early stages, this recent discussion about making the pod requirement for exclusive resources more explicit also indicates a need for non-FG capabilities. The API field itself should be forward-facing enough to support such potential use-cases ?. |
Those are all examples of FG-related capabilities. Not the generic long-term capabilities. |
5fb093d
to
a3e1436
Compare
It seems like most of the concerns with this are around the specific capabilities being added, but this KEP doesn't actually propose adding any capabilities. The examples given are hypothetical examples based on features currently in development, but no new features will be able to depend on capabilities until it goes to beta. This creates a bit of a chicken-and-egg situation, where it's hard to point to exactly how capabilities will be used until we have users lined up, but we can't line up users yet. |
we kind of need to know what will be expected use cases. Maybe past examples or hypothetical examples thought thru end-to-end. Right now this KEP is limited to just set of name/value pairs and a scenario of FG discoverability. But already we are thinking there MAY be need to support capabilities for node selection, ability to declare tolerations for capabilities, ability to have node-restricted capabilities. Knowing the scope would help to understand if API proposed is needed (among alternatives if the set of use cases is limited) and if needed, what shape should it have. |
a3e1436
to
f069f62
Compare
8d6230d
to
cd6d67e
Compare
I have tried to address these the Case Study section. |
I feel like we've discussed these options in depth already. Yes, these are all somewhat hypothetical because we've had to work around them in other ways. I'm sure we can dig up more examples from past KEPs, but is that necessary? Capabilities that are not limited to just feature gates:
Feature gate capabilities:
Not sure what node selection means, but we've explicitly said tolerations are out of scope.
Where did this come in? Capabilities are just added by the node, so I'm not sure what this would even mean. |
We discussed this KEP today and decided to re-consider this for 1.35 release cycle. The primary reason is to get input from Few more things discussed and that could be refined in the proposal:
|
This proposal was discussed in the SIG-Arch community meeting on June 26th (recording), It was generally seen as a beneficial strategy for managing version skew. The key takeaways and action items from the discussion are as follows:
I will incorporate this feedback into the KEP and reach out when its ready for review. |
cd6d67e
to
eff4d75
Compare
eff4d75
to
1313dd7
Compare
1313dd7
to
fc48bfb
Compare
I've updated the KEP based on the SIG Architecture feedback (#5347 (comment)). The new version focuses more on capabilities tied to the feature lifecycle and expands on the deprecation strategy. @tallclair @SergeyKanzhelev @haircommander @wojtek-t PTAL when you get a chance. |
Uh oh!
There was an error while loading. Please reload this page.