RemoteFS share configuration improvements

Registered by Eric Harney on 2013-11-13

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.

Blueprint information

Status:
Complete
Approver:
Mike Perez
Priority:
Medium
Drafter:
Eric Harney
Direction:
Approved
Assignee:
Eric Harney
Definition:
Approved
Series goal:
Accepted for kilo
Implementation:
Implemented
Milestone target:
milestone icon 2015.1.0
Started by
Mike Perez on 2015-01-26
Completed by
Mike Perez on 2015-02-15

Related branches

Sprints

Whiteboard

https://review.openstack.org/#/c/149765/

Where are things at with Manilla? Honestly we need to either have Manilla ready and building a shares service on top of block devices, or get a *real* service in Cinder that does it. I know in the past we started down that path and punted but a lot of time has passed and quite a few things have changed.

Continuing to try and force-fit share semantics in Cinder obviously doesn't work. We need to resolve this and go in one direction with focus and not be half in half out any more.

There are numerous issues with how shares are setup in Cinder right now, some very serious issues that need addressed, I don't want to keep band-aiding something that's already fundamentally broken.

EH> This is not about file share semantics. It's about addressing shortcomings in how to configure storage backends for NFS/GlusterFS volume drivers, since they both support the notion of multiple backend stores for a single driver instance but don't really provide enough tools to manage that correctly. The interest is still only in providing normal Cinder volume services.

EH edit> To add to the above... this is also aiming to fix things like the inability to change the address of a storage backend server, which is a problem even if you don't have the multiple-backend notion.

deepakcs > Eric, do you think the BZ @ https://bugzilla.redhat.com/show_bug.cgi?id=991490 (i.e. ability to honor -o options after shares were mounted ) fall into this blueprint as well ? If yes, i would like to put this BZ as RFE and start to work on the larger goal this blueprint targets ?

Duncan Thomas> While it keeps coming up, I'm not sure that Manilla is relevant to this discussion. Manilla provides file-share exposure to the VM, cinder provides block. These are fundamentally different, and I wouldn't like to see them overlap. The fact that the block backing file is hosted on a file share rather than a ISCSI target is pretty incidental compared to the block .v. file exposure to users.

Gerrit topic: https://review.openstack.org/#q,topic:bp/remotefs-share-cfg-improvements,n,z

Addressed by: https://review.openstack.org/133173
    RemoteFS configuration improvements

Gerrit topic: https://review.openstack.org/#q,topic:bp/remotefs-cfg-improvements,n,z

Addressed by: https://review.openstack.org/149765
    RemoteFS: Use nas_ip and nas_share_path options

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.