----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6900/#review11251 -----------------------------------------------------------
With the current implementation the pool has to be marked as removed prior to starting the removal process. Otherwise it makes it available for new volumes creation while the pool is going through removing stage. The correct fix would be: * introduce the "state" field for the storage pool. Having 3 values for this state should be sufficient enough by now: Created, Removing, Removed. Created would be the initial state * when delete is called for the storage pool, update the pool with Removing state, don't update the Removed field yet. Check all the cloudStack storage operations to ensure that the storage pool in Removing state can't be used for any operations requiring storage access * After the removal is successful, update state to Removed, and set Removed field to not null date value. Also make sure that: * deleteStorage api can be called on the storage pool with Removing state. * better introduce state machine for storage state management, it will make code more readable. - Alena Prokharchyk On Sept. 4, 2012, 3:10 p.m., Gavin Lee wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/6900/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2012, 3:10 p.m.) > > > Review request for cloudstack and Alena Prokharchyk. > > > Description > ------- > > Keep the remove operation transactional which avoid partial updated when > exception occurs. > > > This addresses bug CLOUDSTACK-10. > > > Diffs > ----- > > server/src/com/cloud/storage/StorageManagerImpl.java 50a78db > > Diff: https://reviews.apache.org/r/6900/diff/ > > > Testing > ------- > > tested and verified the fix works correctly. > > > Thanks, > > Gavin Lee > >
