gluster_native: same volumes are re-used with vol mapped layout after restarting manila services

[karthick]

Unlike directory based layout, with volume mapped layout a complete volume is picked to create a share. Volume thus picked should be used to create only one share.

However, shares created after manila service restart picks the volume once again although there is already a share created out of it. This is not expected.

Steps to reproduce:

1) create a backend gluster volume
2) create a share from the volume created above
3) Attempt to create share once again - share creation fails as there are no volumes to pick up - This is expected
4) restart all manila services - m-shr, m-api and m-sch
5) Attemp to create share once again - share gets created on volume which was already used in step 1

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit e91632b6e2ff34d9bf0be52f6ac7d5d2a7520245
Author: Csaba Henk <email address hidden>
Date: Sat Oct 10 01:23:11 2015 +0200

    glusterfs/volume layout: fix incorrect usage of export_location

    Actually, all uses of export_location are incorrect -- from the
    layout code's point of view, export_location is an arbitrary
    opaque value, obtained from self.driver._setup_via_manager with
    which the only legit action is to return it from create_share*.

    That we use export_location as dict key in ensure_share is just
    a pre-layout relict that survived by the virtue of remaining
    unnoticed. Now the referred bug forced it out of the dark.

    Change-Id: I965dae99486002f00145daff0cd2a848777b5b81
    Partial-Bug: #1501670

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/249999

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/249999
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=085b241de9e4098cdd92c46e9b57c5f24956db8e
Submitter: Jenkins
Branch: stable/liberty

commit 085b241de9e4098cdd92c46e9b57c5f24956db8e
Author: Csaba Henk <email address hidden>
Date: Sat Oct 10 01:23:11 2015 +0200

    glusterfs/volume layout: fix incorrect usage of export_location

    Actually, all uses of export_location are incorrect -- from the
    layout code's point of view, export_location is an arbitrary
    opaque value, obtained from self.driver._setup_via_manager with
    which the only legit action is to return it from create_share*.

    That we use export_location as dict key in ensure_share is just
    a pre-layout relict that survived by the virtue of remaining
    unnoticed. Now the referred bug forced it out of the dark.

    Change-Id: I965dae99486002f00145daff0cd2a848777b5b81
    Partial-Bug: #1501670
    (cherry picked from commit e91632b6e2ff34d9bf0be52f6ac7d5d2a7520245)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/232293
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=3537be25165e96a44254b66f13ea508f60f57af0
Submitter: Jenkins
Branch: master

commit 3537be25165e96a44254b66f13ea508f60f57af0
Author: Csaba Henk <email address hidden>
Date: Thu Oct 8 02:27:37 2015 +0200

    glusterfs/volume layout: indicate volume usage on volumes themselves

    With volume layout, share-volume association was kept solely
    in the manila DB. That is not robust enough, first and
    foremost because upon starting the service, the manager
    will indicate existing share associations only of those
    volumes whose shares is in 'available' state.

    We need to know though if a volume is in a pristine state or
    not, regardless of the state of their shares. To this end,
    we introduce the 'user.manila-share' GlusterFS volume option
    to indicate manila share association -- made possible by
    GlusterFS allowing any user defined option to exist in the
    'user' option name space --, which indicator remains there
    until we explicitely drop it in `delete_share`. (The value
    of 'user.manila-share' is the id of the share owning the
    volume).

    As a beneficial side effect, this change will also provide
    insight to the Gluster storage admin about usage of the
    Manila volume pool.

    Change-Id: Icb388fd31fb6a992bee7e731f5e84403d5fd1a85
    Partial-Bug: #1501670

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/260089

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/260089
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=bd9fef73daa329380675dee0485716ba2fdc0dff
Submitter: Jenkins
Branch: stable/liberty

commit bd9fef73daa329380675dee0485716ba2fdc0dff
Author: Csaba Henk <email address hidden>
Date: Thu Oct 8 02:27:37 2015 +0200

    glusterfs/volume layout: indicate volume usage on volumes themselves

    With volume layout, share-volume association was kept solely
    in the manila DB. That is not robust enough, first and
    foremost because upon starting the service, the manager
    will indicate existing share associations only of those
    volumes whose shares is in 'available' state.

    We need to know though if a volume is in a pristine state or
    not, regardless of the state of their shares. To this end,
    we introduce the 'user.manila-share' GlusterFS volume option
    to indicate manila share association -- made possible by
    GlusterFS allowing any user defined option to exist in the
    'user' option name space --, which indicator remains there
    until we explicitely drop it in `delete_share`. (The value
    of 'user.manila-share' is the id of the share owning the
    volume).

    As a beneficial side effect, this change will also provide
    insight to the Gluster storage admin about usage of the
    Manila volume pool.

    Change-Id: Icb388fd31fb6a992bee7e731f5e84403d5fd1a85
    Partial-Bug: #1501670
    (cherry picked from commit 3537be25165e96a44254b66f13ea508f60f57af0)