Skip to content
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

rbdplugin: provision seperately from node controller #93

Closed
pohly opened this issue Oct 17, 2018 · 1 comment
Closed

rbdplugin: provision seperately from node controller #93

pohly opened this issue Oct 17, 2018 · 1 comment

Comments

@pohly
Copy link
Contributor

pohly commented Oct 17, 2018

I'd like to deploy the rbdplugin a bit differently: instead of running it on each node, I want to handle provisioning in one pod that has external-provisioner+external-attacher+rbdplugin. Then rbdplugin can get deployed as NodeServer only on those nodes which are supposed to use it, or not at all (for example, when only testing provisioning).

This kind of deployment is currently possible, but could be simpler: the fix for #86 introduced a call to nsenter.NewNsenter that is executed before starting the gRPC service. It fails unless the provisioner pod has the /rootfs mount, which isn't actually needed. It would be better if the nsenter was done only when needed, for example when a NodeServer.PublishVolume call is invoked. The result could be cached for reuse in future calls.

@ShyamsundarR
Copy link
Contributor

@pohly The current deployment manifests do this exactly. The provisioners are deployed as a deployment with leader election and the nodeplugin is deployed on all nodes. (rbd manifests are provided as an example, cephfs manifests are similar).

I am closing this issue as the current state reflects required intent of this request.

Rakshith-R referenced this issue in Rakshith-R/ceph-csi May 26, 2022
Sync rhs/ceph-csi:devel with ceph/ceph-csi:devel
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants