glusterFS_NFS_driver: unable to NFS mount manila share with volume mapped layout

[karthick]

Attempt to NFS mount a volume mapped layout share created using manila fails. we do the following changes on the gluster volume while trying to setup NFS using vol mapped layout,

a) set 'nfs.export-volumes' to off
b) set 'nfs.export-dir' to / and allowed access based on IP.

Volumes are by default mounted to / and by setting 'nfs.export-volumes' off, we disable access to any client. A better way to provide volume based access is,

a) set 'nfs.export-volumes' on
b) and control access suing option 'nfs.rpc-auth-allow'

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/225117

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/225117
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=2153b5fa473af9e8bd207935eccd8dc47d7ad07a
Submitter: Jenkins
Branch: master

commit 2153b5fa473af9e8bd207935eccd8dc47d7ad07a
Author: Csaba Henk <email address hidden>
Date: Fri Sep 18 13:48:00 2015 +0200

    glusterfs: fix gluster-nfs export for volume mapped layout

    The nfs.export-dir option is not suitable for specifying
    whole volume exports (ie. exports for root directory).

    Instead, we have to have nfs.export-volumes = on (contrary
    to all other scenarios), and control the export via
    the nfs.rpc-auth-{allow,reject} options.

    So we subclassed GlusterNFSHelper to GlusterNFSVolHelper,
    a new helper class that operates with a similar logic to
    its parent, just works with nfs.rpc-auth-{allow,reject}
    instead of nfs.export-dir.

    The driver code detects if {allow,deny}-acces is performed
    with a whole volume backend and if the helper given in
    configuration is GlusterNFSHelper, then for the handling of
    this call it switches over to GlusterNFSVolHelper.

    NOTE: What we *don't* do: we don't set nfs.export-volumes to "on",
    it's expected to be done by the admin, beforehand. The reason
    is that nfs.export-volumes is not a per-volume option, but a
    per-cluster and we don't want to mess up the access control of
    the cluster by chance in an over-permissive way. The per-cluster
    scope of nfs.export-volumes also implies that using a GlusterFS
    backed with gluster-nfs export mechasim and volume mapped layout
    is an exclusive choice: the cluster can't host it along with other
    export / layout schemes.

    Change-Id: Ie4e4d03608f7a380cae790d429f88a5482d88ac8
    Closes-Bug: #1495910