search

openebs / zfs-localpv

Dynamically provision Stateful Persistent Node-Local Volumes & Filesystems for Kubernetes that is integrated with a backend ZFS data storage stack.
https://openebs.io
Apache License 2.0
422 stars 103 forks source link

PV auto-naming by namespace/pvc name #402

Open Blackclaws opened 2 years ago

Blackclaws commented 2 years ago

Describe the problem/challenge you have The pv/dataset names do not map easily to pvcs when looking purely at the zfs datasets and not having the kubectl output to compare.

Describe the solution you'd like Allow a naming scheme for datasets that follows: namespace/pvc-name-uuid (for deduplication purposes on recreating previously bound volumes). This would allow you to easily pick out the datasets containing specific data from for example a remote backup without having to cross reference kubectl get pv.

ukd1 commented 1 year ago

I would also love this!

Abhinandan-Purkait commented 4 months ago

@Blackclaws Can you provide a detailed explanation for the same. Including what names you used for pvc and what names you are expecting for the k8s PV and zfs datasets.

ghormoon commented 4 months ago

I had very similar idea, but i missed this request and i created #520

This approach would be enough also for me, but it would be even better, if it could also be done without the uuid part. Or maybe made customizable by some patter string that could fill in namaspace, pvc name, uuid, like %n/%p-%u (for the case shown in this request), but i guess that's unnecessary complex.

The advantage of being able to customize it and do just %n/%p would allow in future for a feature to "adopt" existing ZFS datasets/volumes. currently you can workaround it by creating those objects manually, but it would be nice to be able to zfs recv from a backup location and just helm install some application in proper namespace and with pvc name set and be good to go with data already restored.

Abhinandan-Purkait commented 2 weeks ago

There is a limit on the max char length of the Kubernetes resources which is 64. How can we ensure that the human-readable name falls within this limit and still be unique always?

tiagolobocastro commented 2 weeks ago

I think this may not possible today, at least for dynamic provisioning, because the k8s csi external-provisioner does not support this. We may only control the prefix of the pv name, and the len of the uuid:

--volume-name-prefix <prefix>: Prefix of PersistentVolume names created by the external-provisioner. Default value is "pvc", i.e. created PersistentVolume objects will have name pvc-<uuid>.

--volume-name-uuid-length: Length of UUID to be added to --volume-name-prefix. Default behaviour is to NOT truncate the UUID.

This would have to be tackled upstream: https://github.com/kubernetes-csi/external-provisioner/issues/1164

Perhaps for static provisioning, when importing existing datasets, this may already be possible since we're creating the PVs ourselves?