Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/remotefs-share-cfg-improvements.

Description:

NFS and GlusterFS shares are added by listing them in a text config file.  This allows management of multiple shares but does not allow for cases like "I changed the address of my NFS server".

This is partly because the volume's provider_location in the database stores an NFS server address, but the user has no way to update that.  Removing an NFS share from the shares config and adding a new one will cause new volumes to be created at the new location, but existing volumes are not handled gracefully.

We need to have a configuration scheme that will allow someone to identify an NFS server as an entity, and change its address, causing the required database rows to be updated by the driver as needed.


Proposal 1:
More robust configuration file which allows an NFS/GlusterFS share to be identified with a unique ID, which has an address, path, options, etc., associated with it.

If the user changes the address/path, the volume service can update provider_location for the required shares.

Requires storing the new unique ID somewhere (presumably a new provider_location format).  Should be backward compatible with current behavior.


Proposal 2:
Actually store share information in the database as entities rather than in shares.conf and manage with an extension API (or cinder-manage).  May enable more complete management than the first option.


Specification URL (additional information):

None