Add support for volumeAttributesClassName in storage configuration

[scholzj]

VolumeAttributesClass introduces to Kubernetes new way how to manage the performance class of the PVCs. Unlike a Storage Class that is immutable, the Volume Attributes Class allows users more flexibility when configuring parameters of the storage such as IOPS, throughput etc. This is something what comes up from time to time from a Strimzi users in our forum. Currently, it is often managed through various annotations. It would be nice to support the configuration of the VolumeAttributesClass / volumeAttributesClassName in PVCs and in out storage configuration.

[scholzj]

Discussed on a community call on 22.8.2024:This would be a useful feature. A proposal should be written to clarify the API changes, storage diffing changes etc.

[venkatesh2090]

Hi, I would like to have a go at this.

Do you reckon this is easy enough for someone new to the code base. I have been able to provision clusters with this feature enabled on AWS, so I am fine with testing this. Couldn't figure it out locally though since the CSI driver for kind doesn't seem to respect this API.

[scholzj]

I do not think this would be too complicated. But as it would include some changes to the API, this needs to have a proposal first. So you would need to start with that.

[venkatesh2090]

I was testing VolumeAttributeClasses (VACs), and the CSI driver would post an error on the PVC if the driverName referred to by the VAC didn't match the provisioner in the StorageClass. I would like to know if it is better to fail in the Cluster Operator or let it apply the changes and let the users discover that error from the PVC? I am leaning towards the latter but want other opinions.

As far as I can tell, the error doesn't occur during admission but after the change is applied by the api server and appears as an event on the PVC

failed to provision volume with StorageClass "sc-example": VAC vac-example referenced in PVC is for driver ebs.csi.aws.co which does not match driver name ebs.csi.aws.com

[scholzj]

I think it is user responsibility to use the VolumeAttributeClass that works with given StorageClass. So if this happens with a new cluster, I guess Strimzi can just fail and the user has to deal with it. The more interesting questions is what happens if someone changes the VolumeAttributeClass for existing volumes. Is it editable property? Or read only?

[venkatesh2090]

Looks like you can edit it. But depends on the cloud provider if it will successfully update. e.g. I see this for an aws cluster. Ig we leave that to the user as well.

  Warning  VolumeModifyFailed     26s (x5 over 66s)      external-resizer ebs.csi.aws.com                                                          rpc error: code = Internal desc = Could not modify volume "vol-0fa7ff557865862c2": volume "vol-0fa7ff557865862c2" in OPTIMIZING state, cannot currently modify

[venkatesh2090]

Had a go at this. Would appreciate a review strimzi/proposals#149