Propagate PVC labels as AWS tags in file systems/volumes

[kanor1306]

Is your feature request related to a problem? Please describe.
My feature request is related with easier monitoring and cost reporting when using dynamic provisioning. I think a common use case for Lustre FSx is having short lived (i.e. a few hours) very performant volumes that are used as storage for jobs.

Lets say that I run a job, and then I want to add a grafana board with information about the job, and part of it is information about the storage I requested. My normal approach if would be to label the PVC with something that helps me link my job with the PVC (and PV). In the case of FSx, what I would like is to label a PVC that used the FSx storage class, and that the labels (or some of them) will also be set as tags of the file system in AWS. Currently, this is not possible with the FSx driver, as the only tagging possible is via Storage Class, making it (if I understand it properly) not dynamic.

This lack of tagging, makes cumbersome to link a workload in Kubernetes with a AWS FSx file system. In the case of Grafana, this can be achieved with some complex query, as you can indirectly link a PVC with its FSx file system via the CSIVolumeName tag (that seems to be the only one automatically created), but it is cumbersome and requires a complex query that is also not very efficient. What is even more difficult is cost monitoring. Ideally I would like to just be able to filter in my cost explorer with a Tag, so I can know the FSx costs for a specific workload.

Describe the solution you'd like in detail
Selected labels of a PVC are set as AWS Tags in FSx file systems and volumes

Describe alternatives you've considered
Some job that does the tagging, but it seems that is a functionality that could make sense to have in the driver

[jacobwolfaws]

Hi @kanor1306, looking at where/how the CSI external provisioner sidecar makes a CreateVolumeRequest(https://github.com/kubernetes-csi/external-provisioner/blob/master/pkg/controller/controller.go#L630#L646), specifically at how it only pulls capacity from the pvc, it seems like there's no path forward for this added functionality due to the limitations of the external provisioner. Do you have an example of this being implemented anywhere else/if someone has found a workaround?

[kanor1306]

@jacobwolfaws actually I thought that it was a common thing to have, but turns out that it is not. I have looked into it a bit more and run into this thread of the EBS driver, kubernetes-sigs/aws-ebs-csi-driver#180 where they discuss this same thing. In the case of the EBS driver they have slightly more flexibility, as they allows some metadata (see https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/tagging.md#storageclass-tagging), but in any case is not enough for my use case.

As you have pointed out this goes down to the external-provisioner, so not much to be done, Thanks for your help!

[kanor1306]

For reference, the discussion about this issue in the external provisioner repo. The original post is about annotations but I think that most of the concerns apply to labels too: kubernetes-csi/external-provisioner#86

[jacobwolfaws]

Thanks @kanor1306 for looking into this more, sorry that we can't hit your specific use-case

For future readers: This seems to be the solution used in the EBS CSI Driver: kubernetes-sigs/aws-ebs-csi-driver#180 (comment) . It's worth exploring as it might yield some benefit for users even if not helpful in this specific case.