GlusterFS volume layout: share zombies haunt forever due to overzealous delete_share
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | OpenStack Shared File Systems Service (Manila) |
Medium
|
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 |
| 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) |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit ec5d9ca466f9ae7
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: I76dabe0acc0b67
Closes-bug: #1554290
| Changed in manila: | |
| status: | In Progress → Fix Released |
This issue was fixed in the openstack/manila 2.0.0 release.
Fix proposed to branch: master
Review: https:/