RemoteFS share configuration improvements
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:
-
2015.1.0
- Started by
- Mike Perez
- Completed by
- Mike Perez
Related branches
Sprints
Whiteboard
https:/
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:/
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:/
Addressed by: https:/
RemoteFS configuration improvements
Gerrit topic: https:/
Addressed by: https:/
RemoteFS: Use nas_ip and nas_share_path options
