local-path-provisioner icon indicating copy to clipboard operation
local-path-provisioner copied to clipboard

Make folder names configurable

Open mossroy opened this issue 2 years ago • 9 comments

Currently, the folder names are created with a hardcoded pattern: pvname_namespace_pvcname (see https://github.com/rancher/local-path-provisioner/blob/master/provisioner.go#L261).

It would be very useful to be able to use a different folder name pattern, like namespace-pvcname or namespace/pvcname

The goal is to have a predictable and stable directory name, which would have several advantages:

  • it would be possible to create and populate the directory before the corresponding PVC is bound (i.e. before deploying the workload). Very useful when you're not starting from scratch, but need to initialize data. Without that improvement, you currently need to deploy the workload first (so that the PVC is bound), then remove it, remove the content of this directory (if any has been added by this first launch), then copy what you need in it, and redeploy the workload
  • it would really simplify some cases of Disaster Recovery Plan. For example, if your cluster is completely unavailable, but you have a copy of the folders (from a backup, for example), you could easily and quickly run it again on another cluster, just by transferring the folders and deploying the same manifests
  • when using a reclaimPolicy set to Retain, it would be much easier to transfer a stateful workload from one node to another one. You would only have to remove the workload & PVC, then move the directory to the target node, modify your workload to make it run on the target node, and deploy it again. Currently, it's more complicated because you have to move the directory content inside the new directory (and you don't know its name beforehand). It would also cover the case of renaming a node
  • when using a reclaimPolicy set to Retain, it would be possible to delete then recreate the PVC while keeping the data. Useful when the PVC has been deleted/recreated (by mistake or on purpose)

The nfs-subdir-external-provisioner has to do something very similar regarding folders, and has implemented what is necessary to make the pattern configurable. See https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/cmd/nfs-subdir-external-provisioner/provisioner.go#L105

mossroy avatar Feb 28 '23 13:02 mossroy