Support CreateVolume

[huchengze]

A complete csi plugin needs to finish its controllerserver.go
https://github.com/kubernetes-csi/csi-driver-nfs/blob/master/pkg/nfs/controllerserver.go.

We can use the code in https://github.com/kubernetes-incubator/external-storage/blob/master/nfs-client/cmd/nfs-client-provisioner/provisioner.go as comparison.

[wozniakjan]

Hi @huchengze, for now the development of this plugin is a little bit slower due to no dedicated full time maintainer, only few hobbyists slowly grinding through the unfinished tasks in their free time. No immediate plan for finishing that in next weeks afaik but if you'd like to submit a PR, we appreciate all help and gladly review to successful merge :)

[msau42]

I do have an implementation of the nfs-client equivalent behavior that provisions subdirectories from an existing nfs server. I would be happy to contribute if you think the nfs-client-like provisioner is the way to go.

Another alternative is that the provisioner creates an entire nfs server, like the ganesha-based nfs external provisioner.

I think it would be hard for a single driver to support both. I think we should just pick one mode for simplicity. There was an attempt in the past to support different provisioning modules via go plugins, but I think there were some challenges with that model: #13

cc @kmova for thoughts

[wozniakjan]

that provisions subdirectories from an existing nfs server

that sounds like a solid implementation, I am in favor of supporting this approach. There might be a path to also support multiple NFS servers in cluster but I think it would make sense to have separate StorageClass for each NFS server and the plugin can obtain connection information from the StorageClass. Kind of like the old ganesha provisioner but without spinning up the entire NFS server, only as a reference point to one created independently.

There was an attempt in the past to support different provisioning modules via go plugins, but I think there were some challenges with that model: #13

this is a very good resource, thanks. Let's see if we can resurrect that PR, I could find some spare time in early May. @huchengze also feel free to chime in, every idea is welcome.

[msau42]

/reopen

[k8s-ci-robot]

@msau42: Reopened this issue.

In response to this:

/reopen

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.

[msau42]

/kind feature

[msau42]

Here's an example StorageClass for my nfs-client equivalent implementation:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-nfs
provisioner: csi-nfsplugin
parameters:
  server: 10.123.42.242
  base-dir: vol1

You specify the nfs share you want to use as the "base". And with every CreateVolume call, it mounts that share, and creates a subdirectory under it, then unmounts it.

[kmova]

I agree with this approach.

I think it would be hard for a single driver to support both. I think we should just pick one mode for simplicity.

@msau42 @wozniakjan - couple of questions related to the scope/implementation:

• Will csi-driver-nfs be considered a replacement for the in-tree NFS driver? Should it support:

  • Managing PV with NFS spec.
  • Managing PV with NFS spec that includes sub-directories

• What are the advantages of going with CSI driver approach for NFS sub directory volumes as opposed to using external-provisioner? One advantage I see is that we can have node driver potentially support volume metrics. (Though metrics could be done via daemonset, CSI approach seems cleaner) . What else?

[msau42]

I think from a driver point of view, we can't really tell the difference between a top level share and a subdirectory. The "share' in the volumeAttributes can be either:

    volumeAttributes: 
      server: 127.0.0.1
      share: /export

The main advantages of the csi driver over the nfs-client external provisioner is that we can potentially support CSI-only features like snapshots and cloning, although a generic driver will be a bit limited in what we can offer. I think snapshots/cloning would basically just be copying directories to another place in the nfs share.

[msau42]

Supporting volume metrics is another useful feature. Do you know if "df" works if you mount a subdirectory in an nfs share?

[msau42]

/assign