StorageClass to PV relationship #41575

kerneltime opened this Issue Feb 16, 2017 · 2 comments


None yet

2 participants

kerneltime commented Feb 16, 2017 edited

This is a continuation of the discussions part of the PR to add Classname attribute to PV and PVC.
There are 2 main concerns

  1. Ability for a backend/provider to be able to validate a storage class being created (Ex: Backend does not have fast disks but storage class consists of fast disks). Today, the storage class will be created but the volume creation will fail. There are no means for the volume provider to have a way to validate a storage class.
  2. The ability to assign a volume to a storage class without any validation. (Ex: a volume that is not fast can be labelled fast via setting the storage class annotation or attribute). This complicates providing any guarantees. Ideally, only volumes created by the provisioner for a storage class should belong to the storage class. Any other functionality should be achieved by using labels instead of using storage class as an attribute.
@kerneltime kerneltime changed the title from StorageClass to volume relationship to StorageClass to PV relationship Feb 16, 2017

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:

  • if PVs are provisioned dynamically using a storage class, it's the provisioner responsibility to put it into the right class (which is already implemented)
  • if the PVs are provisioned manually by cluster admin, it's his/her responsibility to put them to the right storage class. Users can then blame the admin for providing a "fast" volume that's not as fast as the user expected.
  1. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment