GlusterFS volume layout: share zombies haunt forever due to overzealous delete_share

[Csaba Henk]

GlusterFS volume layout stores the location of the backing storage of a share via private_storage.

In delete_share that location is retrieved from private_storage, from which we proceed on to the actual deallocation of the physical resource. However, this retrieval is unconditional / unguarded, so if any problem occurs with that, deletion fails. This implies that for shares for which allocation of the backing storage has failed, and thus they are in error state, cannot be cleaned away via delete_share, because they don't have a resource location stored in private_storage and so it cannot be retrieved and thus delete_share fails.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit ec5d9ca466f9ae7a2ee6ec5605b357b06ee1f3ac
Author: Csaba Henk <email address hidden>
Date: Mon Mar 14 00:34:26 2016 +0100

    glusterfs volume layout: take care of deletion of DOA shares

    In delete_share, if private_storage entry of share is
    missing, recognize this as indication of a botched
    creation and return immediately so that the runtime
    can go on with evicting the dangling share entry.

    Change-Id: I76dabe0acc0b67ea2b03e77eb0743772ef25579d
    Closes-bug: #1554290

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/manila 2.0.0 release.