Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of shadowsor@gmail.com
 designates 209.85.214.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACOnxCiZ=fNqReZbvVyzimQNi6ft+VUHJhzQT6mY9dfHeWAHLw@mail.gmail.com>
References: 
 <CALFpzo5jeMQjtJctL6esv+TLGoWB1sJ+vJKygT0akBxUzcg9CA@mail.gmail.com>
	<CACOnxCiZ=fNqReZbvVyzimQNi6ft+VUHJhzQT6mY9dfHeWAHLw@mail.gmail.com>
Date: Thu, 30 Jan 2014 15:29:28 -0700
Message-ID: 
 <CALFpzo6AGtO1yXO0q3tNOPLTqkDrS-d-RU0kteCHiKB0ymLdww@mail.gmail.com>
Subject: Re: volume lifecycle issue expunging
From: Marcus <shadowsor@gmail.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

My one hesitation is that it may cause problems by surfacing other
bugs. For example, say a delete operation succeeds in deleting the
image file, but fails in some subsequent code. The next time it runs,
it may fail in deleting the image file (file not found), and thus get
stuck in an endless loop trying to clean up.  I think it's ultimately
good to surface those (better than potentially orphaning disks on
storage), but it may be something to watch for.

On Thu, Jan 30, 2014 at 2:56 PM, Mike Tutkowski
<mike.tutkowski@solidfire.com> wrote:
> I agree, Marcus.
>
>
> On Thu, Jan 30, 2014 at 2:42 PM, Marcus <shadowsor@gmail.com> wrote:
>
>> I think there's a hole in the volume lifecycle.  I've been noticing
>> volumes lingering that should have been cleaned up, and it seems to be
>> a bug in the state machine for the volumes:
>>
>>             s_fsm.addTransition(Destroy, Event.ExpungingRequested,
>> Expunging);
>>             s_fsm.addTransition(Expunging, Event.ExpungingRequested,
>> Expunging);
>>             s_fsm.addTransition(Expunging, Event.OperationSucceeded,
>> Expunged);
>>             s_fsm.addTransition(Expunging, Event.OperationFailed,
>> Expunging);
>>
>> If a volume is in Destroy state, it goes to Expunging when the delete
>> operation is requested. If the delete fails, it remains in expunging.
>> The storage garbage collector will never try to clean up that volume
>> again, since it only lists volumes in 'Destroy' and attempts those.
>> You can only get to Expunging from Destroy, it makes sense to change
>> that last line to revert the volume state back to Destroy if the
>> expunge operation failed, so that it will try again next time.
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*