PV and volume naming from PVC

[JohnStrunk]

Describe the feature you'd like to have.
The Gluster volume name that backs a PV/PVC should be easily recognizable, given the PVC name and namespace.

What is the value to the end user? (why is it a priority?)
Some organizations have defined IT processes wherein they need to be able to access data that resides within a PV from outside the kube cluster. One example of this is an IT department that uses a legacy (non-containerized) backup application for backing up containerized application data. In these cases, they need to be able to easily locate the Gluster volume that holds the data for an application.

How will we know we have a good solution? (acceptance criteria)

• If an admin knows the name of the PVC and the Namespace within which it resides, they should be able to easily locate the correct Gluster volume by querying GD2 directly.
• There must be a way to ensure there are no collisions in volume names. This is a concern primarily if the PVC name is used to set the volume name
• These same capabilities should apply to snapshots (once implemented)

Additional context

• It's not clear if this is possible today, given just the CSI interface.
• One implementation may be to influence the volume name, but GD2 volume-level tags could also be used.
• This feature currently exists for Heketi-based deployments

[Madhu-1]

what the difference between this issue and #71

[JohnStrunk]

what the difference between this issue and #71

2 weeks and my poor memory. 😞
Thanks for catching it.

---

Bringing across details from #71:

• OCS 3.10 uses the format: <prefix>-<pvc_namespace>-<pvc_name>-UUID

Addl AC:

• The backup host shouldn't need to directly query the kube API
• The solution should work efficiently even with 1000s of volumes
• It needs to be able to recognize scenarios where a PVC is deleted and recreated with the same name/ns.
• These capabilities should be applicable to restore as well.