Wrongly using /buckets/<volumeId > when path is specified in volume

[Ruakij]

Problem

By default, the driver will use the volumeId to create a new folder under /buckets/<volumeId>. This also gets deleted when the volume is deleted.

But as we can override the path given to the filer by setting spec.csi.volumeAttributes.path, this doesnt work then.

Behavior

• Create PV
  • Folder is not created
• Delete PVC attached to PV (with policy Delete)
  • Error because folder doesnt exist. PV stays marked with "Error" and has to be removed manually
• Mounting
  • Mounter doesnt complain the filer.path doesnt exist. Files can be created, etc, but are inaccessible from parent-directories. (Bug in weed mount or filer to allow this?)

Expected Behaviour

• When creating a volume:
  • specified path is created if it didnt exist
• When deleting a volume:
  • specified path is deleted
  • I'd propose having a flag to not create/delete anything as this can be dangerous and unwanted when provisioned statically
• Mounting
  • When filer.path doesnt exist, error. (or auto-create?)
  • This can happen when the folder was deleted after the Volume is created.

Steps to recreate

1. Create PersistentVolume with custom path

   apiVersion: v1
   kind: PersistentVolume
   metadata:
   name: test
   spec:
   capacity:
   storage: 20Gi
   csi:
   driver: seaweedfs-csi-driver
   volumeHandle: test
   volumeAttributes:
     path: /mytest
   accessModes:
   - ReadWriteOnce
   persistentVolumeReclaimPolicy: Delete
   storageClassName: seaweedfs
   volumeMode: Filesystem

2. Create PersistentVolumeClaim to bind PersistentVolume

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
   name: test
   spec:
   resources:
   requests:
     storage: 20G
   volumeMode: Filesystem
   accessModes:
   - ReadWriteOnce
   storageClassName: seaweedfs

3. Check filer, see no path /mytest is created Interestingly, also the path /buckets/test doesnt exist.
4. Delete PVC
5. See PV being marked as "Error" in Kubernetes. (not sure if the driver-log also contains errors)

---

CreateVolume:
https://github.com/seaweedfs/seaweedfs-csi-driver/blob/d777b8750bb2dd33948988f4eec8813e6207a0cd/pkg/driver/controllerserver.go#L53 DeleteVolume:
https://github.com/seaweedfs/seaweedfs-csi-driver/blob/d777b8750bb2dd33948988f4eec8813e6207a0cd/pkg/driver/controllerserver.go#L83 ValidateVolumeCapabilities:
https://github.com/seaweedfs/seaweedfs-csi-driver/blob/d777b8750bb2dd33948988f4eec8813e6207a0cd/pkg/driver/controllerserver.go#L127

---

Depending on what we want to allow, we could ideally get the path of the volume and operate on that. This would then be equivalent to volumes which dont have a path set.
Though i am not sure how hard it is to get that information as its not passed with the Request.

From what i observed, the CreateVolume isnt even called when a PV is created, only when it happens through a PVC?
Maybe this is an expected behaviour?

[n9]

What I have found yet:

• path was introduced in https://github.com/seaweedfs/seaweedfs-csi-driver/commit/5c2298bd215959d78c881e5d48d96569b83ab3c7, it replaced older bucketName
• but it seems to me that the same issue was with the bucketName

I seems to me that path should be also handled in controllerserver, not just in nodeserver (via mounter).

@kvaster, are you using path? In what case it is working for you?

[kvaster]

There are at least two ways of using seaweedfs:

• Create path (PV) automatically - RWO. Here we need to create / allocate bucket and to delete it later.
• Use common/shared path - RWX. Here we need just a path and we really don't need to delete this path.

I will recheck logic and will get back.