enhancements
enhancements copied to clipboard
kubernetes
KEP-4742: Expose Node Labels via Downward API
- Adding new KEP 4742: Expose Node Labels via Downward API
- Issue link: https://github.com/kubernetes/enhancements/issues/4742
- Other comments: In response to discussion here: https://github.com/kubernetes/kubernetes/issues/40610
Welcome @docandrew!
It looks like this is your first PR to kubernetes/enhancements 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.
You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.
You can also check if kubernetes/enhancements has its own contribution guidelines.
You may want to refer to our testing guide if you run into trouble with your tests not passing.
If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!
Thank you, and welcome to Kubernetes. :smiley:
Hi @docandrew. 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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
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.
As discussed at https://github.com/kubernetes/kubernetes/issues/40610 this is open a lot of concerns around security
As discussed at kubernetes/kubernetes#40610 this is open a lot of concerns around security
I think we can do this in a safe way. Let me know if the reply makes sense. Happy to work through this and give examples.
As discussed at kubernetes/kubernetes#40610 this is open a lot of concerns around security
I think we can do this in a safe way. Let me know if the reply makes sense. Happy to work through this and give examples.
After reading the entire conversation on the KEP issue and related links, I am ok with this now. As NFD maintainer I am eager to help here, as NFD creates labels for the underlying infra
some concerns to address: https://github.com/kubernetes/kubernetes/issues/40610#issuecomment-2189848266
Notes I got from the meeting so they can be fixed and address later when there is time:
- [ ] Document behavior around restarts as it relates to fileMounts and env (values may change)
- [ ] Elaborate/Fix use-cases (can't use vpn for example based on fixed values)
updated since we are not considering using kubelet flags
I am -2 on kubelet flags. In most managed providers, those flags are not accessible to users or admins, and differeing opinions between providers will make portability WORSE, not better.
We'd do better to define a small set of extension mechanisms and leave it fixed at that.
Just as an after thought https://github.com/kubernetes-sigs/node-feature-discovery/issues/1779
I have put together an example implementation (NOT setting via the kubelet however) to gather feedback on approaches here: https://github.com/kubernetes/kubernetes/pull/127092 - hopefully this can help facilitate some discussion!
I think KubeRay would really benefit from this proposal in order to propoagate node topology into the Raylet. Are we planning to push this forward in v1.32?
I'd love that but will likely need some hand-holding to help shepherd this through the process.
@munnerz has a POC of some parts of this - the question to be answered is what are the tradeoffs we are making between different approaches, and which do you think are "best".
I'd love that but will likely need some hand-holding to help shepherd this through the process.
I'd be happy to help - I'll ping you on slack 😊
Edit: or ping me @munnerz as I'm not 100% sure which slack account is yours 👀
I see some pushes but I don't know if that means "please go read it again" or if it is still in-progress. I will assume the latter (WIP) until I hear otherwise.
Not quite ready yet - I think @munnerz was going to add some additional details and hopefully correct me on some things, but getting close!
Can we prioritize this for v1.33? Seems like all the pieces are there but we just need to make some final changes to the KEP. I'm happy to drive this if there are no owners.
@munnerz SIG Node is doing planning for 1.33 now. Do you want to continue owning this or pushing this forward?
@munnerz @docandrew do you have any plans to continue pushing this for v1.33?
@andrewsykim I think I addressed most of the concerns in the KEP verbiage itself, which should match the proof-of-concept implementation PR that @munnerz wrote. I'd still like to see it adopted, perhaps in v1.33.
@docandrew thanks -- in Oct you added this comment:
Not quite ready yet - I think @munnerz was going to add some additional details and hopefully correct me on some things, but getting close!
And I haven't seen any updates since. Can you update the KEP with additional details and let us know when it's ready for review?
@docandrew gentle ping on my last comment. Keep in mind production readiness freeze is Feb 6th and KEP freeze is Feb 13th
Thank you for following up - from my point of view it's ready for re-review.