Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Content-Type: multipart/alternative;
 boundary="===============0290292943203680609=="
MIME-Version: 1.0
Subject: Review Request: add state change in createVolume back to Allocated if
 anything fails
From: "Marcus Sorensen" <shadowsor@gmail.com>
To: "Chip Childers" <chipchilders@apache.org>
Cc: "Marcus Sorensen" <shadowsor@gmail.com>,
 "cloudstack" <cloudstack-dev@incubator.apache.org>
Date: Fri, 19 Apr 2013 04:59:42 -0000
Message-ID: <20130419045942.15138.47259@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: "Marcus Sorensen" <noreply@reviews.apache.org>
Reply-To: "Marcus Sorensen" <shadowsor@gmail.com>

--===============0290292943203680609==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10623/
-----------------------------------------------------------

Review request for cloudstack and Chip Childers.


Description
-------

createVolume changes the volume state from 'Allocated' to 'Creating', but h=
as no code to change it back to 'Allocated' if anything goes wrong, despite=
 there already being a path from 'Creating' to 'Allocated' for volumes, via=
 the OperationFailed event. Adding this in fixes the issue and avoids leavi=
ng disks in an unusable state.


This addresses bug CLOUDSTACK-2104.


Diffs
-----

  server/src/com/cloud/storage/StorageManagerImpl.java 624361f =


Diff: https://reviews.apache.org/r/10623/diff/


Testing
-------

Tested in devcloud-kvm, volume that was larger than primary storage failed =
to attack, and went back to 'Allocated' from 'Creating' upon the failure. I=
 was then able to retry, and delete the disk.


Thanks,

Marcus Sorensen


--===============0290292943203680609==--