add additional directory for driver to mount on the host

[jsloyer]

needed to talk to the kubelet

[timoreimann]

Is this to support a kubelet root directory alternative to the default /var/lib/kubelet (i.e., your deployment of kubelet diverges from the default)?

[jsloyer]

@timoreimann yeah if that’s ok.

[timoreimann]

I can totally see how you (and others) may want to use a non-standard directory. What I'm not too sure about is whether adding additional mount points is the right way to achieve that. At the least, it could be surprising/confusing to users to see several mounts where only one is effectively used.

My suggestion would be to keep the manifests as-is and adjust your local copy to your needs. It's also possible to use one of the many manifest management tools out there to keep upstream (i.e., our manifests) unchanged and put customizations on top in a maintainable fashion. Examples are kustomize, kpt, and ytt.

Let me know if that works for you.

[sandaymin123]

The current changes should work out-of-the box across all environments and configs. If we want something easy
without adding additional work on the end-user.

name: plugin-dir
              mountPath: /csi
            - name: pods-mount-dir
              mountPath: /var/lib/kubelet
              # needed so that any mounts setup inside this container are
              # propagated back to the host machine.
              mountPropagation: "Bidirectional"
            - name: kubelet-data-dir
              mountPath: /var/data/kubelet
              # needed so that any mounts setup inside this container are
              # propagated back to the host machine.
              mountPropagation: "Bidirectional"
            - name: device-dir
              mountPath: /dev 

If we want something where the user must override then we must have a supported deployment mechanism that can be templatized or passed based on the environment being deployed. Ideally, these kustomizations or whatever method should be kept at the upstream directory of digital ocean

[sandaymin123]

We should agree on that tooling first

[sandaymin123]

Alternatively, an operator is the best option but that is more work

[timoreimann]

Right, the approach to customize depends a lot on the tool. For instance, kustomize and kpt can operate on upstream resources that don't support customization whatsoever, whereas Helm charts are (to my knowledge) usually bundled with the upstream source.

We also had an external contributor starting the work to support Helm (#382) but unfortunately couldn't carry the effort onward anymore due to time constraints. We'd be happy to see other contributors step up.

[timoreimann]

I'll be closing this PR as I think the better approach to provide flexibility with regards to the mount points (and potentially other parts of the configuration) is in tooling such as Helm, kpt, and kustomize. Helm support would ideally be maintained in this repo, for which we'd be happy to accept PRs. The other tools should allow customization without changes to the driver repo.