/kind feature
Currently, the cinder-csi-plugin supports a restricted set of StorageClass parameters. There is no mechanism to inject arbitrary Cinder Volume Metadata during the CreateVolume workflow.
In our environment, we use a sidecar agent that watches for volume attachments and enforces iotune values on the libvirt layer based on volume metadata. Using OpenStack Volume Types for this is non-viable because:
- Type Explosion: Managing hundreds of types for different IOPS/Billing permutations is unscalable.
- Performance Impact: In many OpenStack backends, a retype (to change QoS/Metadata) triggers a physical migration of data. Performing a data migration on a volume that is already performance-starved just to update a metadata hint is counter-productive.
Describe the solution you'd like
I propose adding a metadata parameter to the StorageClass. These key-value pairs should be parsed and passed into the Metadata field of the volumes.CreateOpts struct when the driver calls the Cinder API via Gophercloud.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gold-tenant-a
provisioner: cinder.csi.openstack.org
parameters:
type: high-performance
# Proposed metadata injection
cinder.xxx/static-metadata/x-iops-limit: "5000"
cinder.xxx/static-metadata/x-billing-code": "34FDVX"
Describe alternatives you've considered
- Unique Volume Types: Too rigid; causes unnecessary physical data movement during QoS adjustments.
The underlying gophercloud/openstack/blockstorage/v3/volumes package already supports Metadata map[string]string in CreateOpts.
I'm willing to contribute to this PR, if everyone agrees it in principle to this feature.
/kind feature
Currently, the cinder-csi-plugin supports a restricted set of StorageClass parameters. There is no mechanism to inject arbitrary Cinder Volume Metadata during the CreateVolume workflow.
In our environment, we use a sidecar agent that watches for volume attachments and enforces iotune values on the libvirt layer based on volume metadata. Using OpenStack Volume Types for this is non-viable because:
- Type Explosion: Managing hundreds of types for different IOPS/Billing permutations is unscalable.
- Performance Impact: In many OpenStack backends, a retype (to change QoS/Metadata) triggers a physical migration of data. Performing a data migration on a volume that is already performance-starved just to update a metadata hint is counter-productive.
Describe the solution you'd like
I propose adding a metadata parameter to the StorageClass. These key-value pairs should be parsed and passed into the Metadata field of the volumes.CreateOpts struct when the driver calls the Cinder API via Gophercloud.
Describe alternatives you've considered
The underlying
gophercloud/openstack/blockstorage/v3/volumespackage already supports Metadata map[string]string in CreateOpts.I'm willing to contribute to this PR, if everyone agrees it in principle to this feature.