What happened?

• When setting a VolumeAttributesClass (VAC) name in PVC for the first time, currently there isn't a way for the user to go back to unsetting VAC name even if it keeps failing and there is no way of setting VAC name successfully on the storage backend.
• When changing a VAC name from A->B, currently there isn't a way for the user to go back to VAC A if it keeps failing and there is no way of changing from A->B successfully on the storage backend.

What did you expect to happen?

• When setting a VolumeAttributesClass (VAC) name in PVC for the first time, there should be a way for the user to roll back (unset the VAC name) if it keeps failing and if there is no way of setting the VAC name successfully on the storage backend.
• When changing a VAC name from A->B, there should be a way for the user to roll back (change VAC name back to A) if it keeps failing and if there is no way of changing from A->B successfully on the storage backend.

How can we reproduce it (as minimally and precisely as possible)?

• Try to set VAC name in PVC for the first time but providing a VAC that is infeasible to set on the storage backend so it will never be successful.
• Try to change a VAC name from A->B but B is an infeasible option for the storage backend so it will never be successful.

Anything else we need to know?

If CSI driver returns an error code that indicates CSI ModifyVolume is infeasible, we should allow the user to roll back the VAC change in PVC.

Kubernetes version

$ kubectl version
# paste output here

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)