This is a continuation of the discussions part of the PR to add Classname attribute to PV and PVC.
There are 2 main concerns
Starting with 2) first:
Most of the internal volume code does not know about storage classes. For example, we have an external NFS provisioner, that provisions a NFS PV. Kubernetes does not have any clue about NFS storage classes and how it could distribute existing PVs among them. NFS provisioning and storage classes are completely opaque to NFS volume plugin.
The same applies to iSCSI, there is an Gluster provisioner under development that will provision iSCSI PVs.
What I would propose here is to keep current behavior:
Ability for a backend/provider to be able to validate a storage class being created
That could be possible for internal provisioners. I can imagine a new interface in internal volume plugins that would be called to check if newly created storage class instance is valid and the plugin understands all parameters and their values. Validator (or a new admission plugin) could then reject creation of invalid classes.
Still, that's only for the internal provisioners. How should we validate storage classes for external provisioners? There is no API that could be used to reject StorageClass when it's created. All we can do is to send events to the class, hoping that the admin notices them.