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

Bug #1554290 reported by Csaba Henk on 2016-03-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Shared File Systems Service (Manila)
Ramana Raja

Bug Description

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.

Changed in manila:
importance: Undecided → Medium

Fix proposed to branch: master

Changed in manila:
assignee: nobody → Csaba Henk (chenk)
status: New → In Progress
Changed in manila:
milestone: none → mitaka-rc1
Changed in manila:
assignee: Csaba Henk (chenk) → Ramana Raja (rraja)

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

Changed in manila:
status: In Progress → Fix Released

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers