Feature Request : Allow created resources to have a name prefix

[peterver]

At the moment when for example a volume is provisioned through CSI it gets assigned a name that is bound to be unique.

Such as pvc-123456789ewqioequwq

This approach works beautifully for a purely machine-based operator. But since there is no way to prefix a resource name it leads to confusion when looking at the digitalocean volumes list, especially when the volumes that are provisioned have different use cases.

As such it would/could be beneficial to allow for a prefix to be set ( a prefix, not an override ).

For example : let's say a pvc creates a 10Gb volume for a mysql backup and one for a mongo backup, the resources created by csi would be something like

• pvc-ewqio4234eew423qquwq
• pvc-jsaldjwui4233oe4234234

Which would be understandable for an automated system, but is not understandable to a human operator just looking at the digitalocean volume list either through doctl or the web interface.

If a prefix is allowed, it could become something like :

• staging-mysql-pvc-ewqio4234eew423qquwq
• staging-mongo-pvc-jsaldjwui4233oe4234234

I have opened a similar feature request that I might do a PR for on CCM, if possible the implementation should align with how the CCM ( if it's a desirable feature request off course ) implementation works so that developers using both the CCM and CSI can easily understand it.

Issue on CCM : digitalocean/digitalocean-cloud-controller-manager#102

[fatih]

Hi Peter,

I've looked into it and I think this is something we can do. As I know the name is not unique and can be changeable easily. However I have to first check out what the best way would to set a prefix (such as via CSI parameters or arguments to the CSI plugin)

[fatih]

So @peterver I looked into it, and this is doable via the StorageClass parameter:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: do-block-storage
  namespace: kube-system
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: com.digitalocean.csi.dobs
parameters:
  volumePrefix: "csi-digitalocean"

And then in our controller.go we can do a:

volumeName := req.Name
// change the name if the storage-class has a prefix option
prefix, ok := req.Parameters[volumePrefixParam]
if ok {
	volumeName = prefix + "-" + volumeName
}

However, I'm not sure how this would be helpful because the there is a single StorageClass option and therefore it's global and not bound to the PVC you're creating. I don't think there is a way to pass down any information from a PVC down to the CSI plugin. I'm going to ask this to #sig-storage to see if this is something we can work on.

[lxfontes]

pls consider consistency with
digitalocean/digitalocean-cloud-controller-manager#102

[wolph]

Any progress on this? Currently the list of volumes in the DO console is pretty much useless to me. That's a shame because it could provide a nice overview and it can be convenient in some debugging cases

[timoreimann]

I started a discussion about customizable volume names some time ago on the Kubernetes Slack. Turned out that an upstream ticket about better naming existed already at kubernetes-csi/external-provisioner#67 but got auto-closed after some time (and PR kubernetes-csi/external-provisioner#334 addressing the issue didn't get accepted). The tl;dr is that changing the volume name from its auto-generate, human-unreadable form to something else could break a few assumption and comes with a few security concerns.

We do have something else upstream that we could leverage for DO: kubernetes-csi/external-provisioner#399 added a flag to enable passing along common metadata information to the request that creates volumes, specifically the PVCs namespace, name, and the PV name. (See the --extra-create-metadata flag description.) What we could do with this information is that we could translate them to tags on the DO volume and subsequently extend the DigitalOcean cloud control panel to display the information conveniently (e.g., by preferring to show the PVC namespace / name combo whenever it's available).

This wouldn't match a fully customizable volume name but might take us close enough to match PVCs/PVs to volumes more easily. Specifically, for more customization we'd probably have to drive for an upstream extension to pass in arbitrary metadata.

Thoughts from folks if that would serve people's use case?

[stujb]

This is the one thing that we are lacking on our provisioning of openshift on Digitial Ocean. Is there likely to be any movement to make it possible to add identifiers to the Digital Ocean volume created via the plugin ?

[steveoliver]

This would be very helpful - in line with how load balancers can be named via service.annotations.kubernetes\\.digitalocean\\.com/load-balancer-name. Anything I can do to help move it forward?

[timoreimann]

I took a quick look at the links / discussions I had posted ~3.5 years ago and compared them with what's available on csi-provisioner (the component responsible for creating DO block storage volumes) today: AFAICT, no new means have been introduced to customize the volume name. The issue seems to persist that the naming scheme is mandated by upstream in order to prevent conflicts and ensure determinism.

I'd hoped that the metadata flag I referred to back then would allow for arbitrary tags to be passed through. Unfortunately, it doesn't look like that's the case: only the PVC name, namespace, and PV name seem to be passed through to the driver. The GCE implementation uses that to create tags on the cloud volume (presumably), but that won't immediately provide for a better name. (I did also spot what looks to be a generic label mechanism in the GCE PD driver; as far as I understand, however, those are specific to the driver instantiation, not the volume.)

Some further digging could be helpful in an attempt to discover some means that I may have missed on my cursory, time-bound discovery. Happy to discuss integration options if anything feasible exists; otherwise, engagement with the CSI group may be required up front to get the necessary logistics in place first.