-
Notifications
You must be signed in to change notification settings - Fork 226
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 ServiceAccount for nfd-worker #782
Conversation
Welcome @mac-chaffee! |
Hi @mac-chaffee. Thanks for your PR. I'm waiting for a kubernetes-sigs 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 |
@mac-chaffee could you add the information in the PR description to the commit message ? (minus links) |
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 this looks good. Just the helm lint does not pass muster so you need to fix that.
Two questions I was pondering:
- should we create the SA by default? I think it's probably easier as it is now and shouldn't have any negative effects (except for perhaps the question why is it created if it's not used for anything by the default deployment)
- Should the kustomize deployment be aligned. Again, I think probably not and it is fine the way it is now
as a note, PodSecurityPolicy is going to be removed at k8s 1.25 so eventually we will not need this IMO. my 2 cents for now:
i think we can create by default, maybe a comment in helm values to explain why we create this for now ?
it would be nice if the two ways to deploy NFD are aligned but it can be added in later if needed. (not sure how common deployment via kustomize is apart of dev/ci env. these to my experience usually dont enable PSP) |
Signed-off-by: Mac Chaffee <me@macchaffee.com> This commit creates a separate ServiceAccount for the nfd-worker like the other components. Even though the nfd-worker doesn't need any special RBAC permissions, this feature is useful for nvidia/gpu-operator (a downstream project) which supports PodSecurityPolicies. But since nfd-worker doesn't have its own ServiceAccount, they've bolted on this feature into their fork, which is giving them issues. PodSecurityPolicies are used to grant special permission to nfd-worker to create hostPath volumes.
e1de52a
to
7ec13f0
Compare
/lgtm |
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.
Looks good @mac-chaffee 👍
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mac-chaffee, marquiz 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 |
This PR creates a separate ServiceAccount for the nfd-worker like the other components.
Even though the nfd-worker doesn't need any special RBAC permissions, this feature is useful for nvidia/gpu-operator which supports PodSecurityPolicies. But since nfd-worker doesn't have its own ServiceAccount, they've bolted on this feature into their fork, which is giving them issues: NVIDIA/gpu-operator#314 https://gitlab.com/nvidia/kubernetes/gpu-operator/-/merge_requests/414#note_854845708
PodSecurityPolicies are used to grant special permission to nfd-worker to create hostPath volumes.