Make folder names configurable

[mossroy]

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

[derekbit]

Yeah, there is a similar request https://github.com/rancher/local-path-provisioner/issues/291.

[derekbit]

We still need to handle the existing volume folders.

Possible solutions are

1. Adding a flag for enabling/disabling the new naming.
2. Search the folder name using pvname_namespace_pvcname first. If not existing, search folder name using the new naming.

Any feedback is appreciated.

[mossroy]

I suppose you had the same situation when you implemented #77 ?

Maybe you could add an optional pathPattern setting, and use pvname_namespace_pvcname as its default value (if not set by the user of this provisioner). I suppose it's enough to make the feature retro-compatible?

IMHO, if the user sets or changes this pathPattern while already having directories, he is responsible of renaming the directories.

[jcpunk]

I'll confess interest in this - specifically for the ability to quickly lift and shift under disaster recovery.

[Skaronator]

Also looking for this feature to make disaster recovery simpler in my home lab. The suggestion in #291 looks great. Just use subdirs like namespace/pvc-name.

[KyleSanderson]

Any update on this?

[KyleSanderson]

@derekbit Happy Anniversary. Any luck with this one?

[derekbit]

@KyleSanderson Can you check whether https://github.com/rancher/local-path-provisioner/pull/385 is good enough?

[KyleSanderson]

@KyleSanderson Can you check whether #385 is good enough?

I think the author wrecked themselves, they only exposed PVC: opts.PVC.ObjectMeta, which doesn't let you get at ${.PVC.namespace}/${.PVC.name} anymore via the template like NFS and other provisioners (one of those screaming why! moments). Are you seeing the same thing?

If someone's going in there, adding https://github.com/Masterminds/sprig should let anyone do anything once all the necessary keys are exposed.