When attempting Volume Modification via Volume Attribute Class (VAC), modifying my volume with no VAC to have the following VAC led to VolumeModifySuccessful, despite fakeParam not being a real mutable parameter for EBS Volumes.
CSI Spec notes that INVALID_ARGUMENT gRPC error code must be returned when CO has specified mutable parameters not supported by the volume.
I would expect that mutable_parameter that EBS CSI Driver does not explicitly support should yield an INVALID_ARGUMENT error. This will be extra important to prevent fake volume modifications if EBS releases a elastic volume property that older versions of EBS CSI Driver do not actually use, because it would lead to volumes that were not actually modified.
How to reproduce it (as minimally and precisely as possible)?
/kind bug
What happened?
When attempting Volume Modification via Volume Attribute Class (VAC), modifying my volume with no VAC to have the following VAC led to
VolumeModifySuccessful
, despitefakeParam
not being a real mutable parameter for EBS Volumes.What you expected to happen?
CSI Spec notes that
INVALID_ARGUMENT
gRPC error code must be returned when CO has specified mutable parameters not supported by the volume.I would expect that mutable_parameter that EBS CSI Driver does not explicitly support should yield an
INVALID_ARGUMENT
error. This will be extra important to prevent fake volume modifications if EBS releases a elastic volume property that older versions of EBS CSI Driver do not actually use, because it would lead to volumes that were not actually modified.How to reproduce it (as minimally and precisely as possible)?
Follow Volume Modification via Volume Attribute Class (VAC) example but with an edited volumeattributesclass.yaml
Anything else we need to know?:
Environment
kubectl version
): 1.29.6