Bug 1041718

Summary: [RFE][cinder]: RemoteFS share configuration improvements
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: openstack-cinderAssignee: Eric Harney <eharney>
Status: CLOSED ERRATA QA Contact: Yogev Rabl <yrabl>
Severity: medium Docs Contact:
Priority: high    
Version: unspecifiedCC: eharney, markmc, nlevinki, scohen, yeylon
Target Milestone: Upstream M3Keywords: FutureFeature, Triaged
Target Release: 7.0 (Kilo)   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/cinder/+spec/remotefs-share-cfg-improvements
Whiteboard: upstream_milestone_kilo-3 upstream_status_implemented upstream_definition_approved
Fixed In Version: openstack-cinder-2015.1.0-2.el7ost Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-05 13:10:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 18:48:15 UTC 
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
Comment 6 Yogev Rabl 2015-07-15 13:44:31 UTC 
verified in 
python-cinder-2015.1.0-3.el7ost.noarch
openstack-cinder-2015.1.0-3.el7ost.noarch
python-cinderclient-1.2.1-1.el7ost.noarch
Comment 8 errata-xmlrpc 2015-08-05 13:10:52 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1548