-
Notifications
You must be signed in to change notification settings - Fork 595
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 support to only run selected CSI services #2316
Add support to only run selected CSI services #2316
Conversation
Welcome @NotTheEvilOne! |
Hi @NotTheEvilOne. 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 I understand the intent here, but it feels smelly to me. Shouldn't we just provide 2 binaries instead? What's the point of running 2 services in a single container anyway? |
Thanks for your valuable questions. I'm sorry to come back to the topic late as I've been on holiday. I both agree and disagree with your idea of two separate binaries. Looking at the Go code:
For that reason it seems to me that the one-binary approach is the least invasive implementation for the cinder and manila CSI drivers. [1] https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/96226fcfe521d0f295c2d258e0c37954e93cfcc9/cmd/gce-pd-csi-driver/main.go#L41 |
Alright, this is a solid argument that other CSI drivers do a similar thing. Could we try to maintain some kind of consistency and rename |
This consistency is not yet found. In fact even another Google CSI driver (gcp-filestore-csi-driver) names it differently (only I've the feeling that "run" is the wrong word as it implies that another process or service is spawned which is not the case. Only registered services changes based on the bool parameters, that's why I named it "provide". I'll change it on demand of course :). Just let me know. Some tests fail currently, I'll need to check if proper testing can be implemented for the new methods introduced. |
/lgtm Please take care of formal requirements - add a release note and fill CLA. |
fb21909
to
a95a7bf
Compare
Hi, I rebased the changes to be compatible with the current state again. I would highly appreciate your support to get this merged :) |
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 pretty good to me, question inline.
if err := cmd.MarkPersistentFlagRequired("nodeid"); err != nil { | ||
klog.Fatalf("Unable to mark flag nodeid to be required: %v", err) | ||
} |
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.
Should we still do it when provideNodeService
is true?
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.
There's a new validation in Driver.SetupNodeService() ensuring that the nodeid
is not empty if required.
Marking it as required sounds wrong if provideNodeService
is false
, marking it only required if provideNodeService
is true
seems to be weird. The description of the PersistentFlag
may be extended to note that it is required for the node service?
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.
Yeah, true, we could update the description, otherwise looks good. Please update that, I'll do /approve
anyway.
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 like changes in this (and other) file are caused by your IDE formatting the code. It's fine, but it makes reviewing more difficult.
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.
Sorry for that. I think the last commit got a bit mixed up as well when I rebased to HEAD. Let me know if I should restructure the commits :)
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dulek 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 |
@NotTheEvilOne can you help create an issue to track this change and |
I added issue #2523 for that PR. Should I add the documentation to this PR or another one so that this one can be merged if no further issues exist? |
We would probably prefer updating the docs in this PR. It can be done in a new commit. |
This commit updates the documentation for the CSI controller and node service providing parameters.
Docs look good for me, leaving the final approval to others. |
These CI errors look unrelated. /retest |
/retest |
2 similar comments
/retest |
/retest |
#2529 should fix the CIs. |
/retest |
Looks like we finally made it :) Do you think we can merge it then? :) |
/lgtm |
What this PR does / why we need it:
This PR adds support to both
cinder-csi-plugin
andmanila-csi-plugin
to execute thecontroller
andnode
services independently.This enables use cases where the CSI driver controller deployment is not running on an OpenStack cloud e.g. in a multi-cloud environment. Furthermore it decouples the node ID discovery (either given or metadata server) from the controller service making workaround like
--nodeid=fake-id
unnecessary. The node ID parameter is no longer required therefore.Which issue this PR fixes(if applicable):
Fixes #2523
Release note: