Able to migrate volumes to another storage class and safer mechanism to prevent paths to be discovered again #75
Description
Motivation
Able to migrate PVs (actually underlying volumes) to another storage class and do not be afraid volumes can possibly be discovered more than once.
Problem
Current PV name (generated from path + class + node) is used as a unique identifier for the path on the node. It has some drawbacks, e.g. cannot change PV naming convention anymore, and users cannot change the storage class name, otherwise, volumes will be discovered again.
For example, at first, a user creates a storage class foo to discovery volumes under /mnt/disks, but find foo name is not a good name and want to change it or simply changed the configuration by accident, volumes under /mnt/disks will be discovered again and new PVs with same paths will be created. Pods which expect to use different PVs under different storage class may mount the same volume.
Solution
- Check PV.spec.path and PV.nodeAffinity, if there is a matching PV in PV cache, skip discovering it
- A discovery path can be configured under more than one storage class, but only one can be enabled for discovering
- Note that all storage classes are able to be enabled for deleting
Benefits:
- Do not depend on PV name, we can use any naming mechanism in future
- It helps the user to migrate volumes to new storage class
Use cases
Name of storage class is changed by accident
In the beginning, alice as system admin uses the following configuration for provisioner:
foo:
hostDir: /mnt/disks
mountDir: /mnt/disks
Some volumes are discovered for storage class foo. Alice changes the storage class name to bar in provisioner configuration:
bar:
hostDir: /mnt/disks
mountDir: /mnt/disks
Volumes under storage class foo will not be created under storage class bar. Only new volumes added in /mnt/disks will be created.
This is safer than the current behavior.
Note that, old volumes under storage class foo cannot be deleted by provisioner in this scenario because current provisioner will skip if storage class is not found in its configuration. (For in-process deleting, provisioner has no way to know mount path in provisioner container without storage class configuration) However, users can add old configuration back to recover deletion.
Migrate volumes to new storage class
In the beginning, alice as system admin uses the following configuration for provisioner:
foo:
hostDir: /mnt/disks
mountDir: /mnt/disks
Alice wants to migrate volumes under /mnt/disks to another storage class bar, she can add a new storage class:
foo:
hostDir: /mnt/disks
mountDir: /mnt/disks
disabledForDiscovery: true # only one storage class for same `hostDir` can be active for discovery (default)
bar:
hostDir: /mnt/disks
mountDir: /mnt/disks
Provisioner now can discover new volumes from /mnt/disks under storage class bar.
When volumes under foo are released and marked persistentVolumeReclaimPolicy=Delete, they will be deleted by provisioner.
When all volumes under foo are deleted, foo storage class can be removed from provisioner configuration. Of course, this is optional.
bar:
hostDir: /mnt/disks
mountDir: /mnt/disks