Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E189C10E93 for ; Thu, 30 Jan 2014 21:57:30 +0000 (UTC) Received: (qmail 43030 invoked by uid 500); 30 Jan 2014 21:57:22 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 42897 invoked by uid 500); 30 Jan 2014 21:57:19 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 42754 invoked by uid 99); 30 Jan 2014 21:57:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jan 2014 21:57:17 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mike.tutkowski@solidfire.com designates 209.85.214.169 as permitted sender) Received: from [209.85.214.169] (HELO mail-ob0-f169.google.com) (209.85.214.169) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jan 2014 21:57:13 +0000 Received: by mail-ob0-f169.google.com with SMTP id wo20so4218947obc.28 for ; Thu, 30 Jan 2014 13:56:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TX8/uF/bj4lHuzLHkV2JeK7276PV916yMn3U7BkrBTI=; b=NWBPPDzNqQUzvmeD4C5hllIcOrGxgJdiukr+7eM/DXzOUxRDJg1Aif71TnRk92kw2A CfGpnWwA5D140qu3rz7nT1er5ucx9EhiigpDDPoDQTvEfcolXVxOdI0YnW7ATDAxnEXN 1PQJpNzuG+lZIIV/WK9udGwHZvm/HPjWs/PzgHIb3AfUevcwzFSr7Q7jnqfgA1kZ5CB9 atVC+rFW1jcVW1O7DU/mdW34xV7BPzwaWZCfN5ayXLHShUR2sLijt1sswKagHo0AVtSg rkfr08aevb8XMfSkEiBXiN+yubfFCdkpthiatH8JEXyzl5JyBcC+Xk+RhGciOy+k4+/5 2qcw== X-Gm-Message-State: ALoCoQnvM+t5Lf+PC1SrbB3rBMvoY2CrUpAHZQGbYTabiTqT492poWnHKvEguJQyPLfUl+JIJYja MIME-Version: 1.0 X-Received: by 10.60.63.102 with SMTP id f6mr2250141oes.76.1391119012264; Thu, 30 Jan 2014 13:56:52 -0800 (PST) Received: by 10.182.114.164 with HTTP; Thu, 30 Jan 2014 13:56:52 -0800 (PST) In-Reply-To: References: Date: Thu, 30 Jan 2014 14:56:52 -0700 Message-ID: Subject: Re: volume lifecycle issue expunging From: Mike Tutkowski To: "dev@cloudstack.apache.org" Content-Type: multipart/alternative; boundary=001a11c25532910f2f04f13722d8 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c25532910f2f04f13722d8 Content-Type: text/plain; charset=ISO-8859-1 I agree, Marcus. On Thu, Jan 30, 2014 at 2:42 PM, Marcus 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 *(tm)* --001a11c25532910f2f04f13722d8--