So does it just need to be async, or is deleteVolume doing too much in both moving the volume to destroy state and expunging? If I transition a volume to 'Destroy' state, the storage cleanup thread comes along and deletes it for me later, similar to how the VMs are expunged. This seems preferable, because one could potentially undelete a volume within the window.
On Wed, Jun 5, 2013 at 7:47 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Hey Marcus, > > To me, it seems like it should be async, as well. > > As far as I know (at least in pre 4.2), unless you are deleting a volume > that has never been attached to a VM, the CS MS would have to have the > hypervisor perform some operation upon the deletion of a CloudStack > volume...and that could take a bit of time. > > > > > On Wed, Jun 5, 2013 at 7:24 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > >> Oh, I should add that I traced it through the system, and it actually >> sends a DeleteVolumeCommand to the agent. That has to finish before >> the sync call completes. >> >> This is on 4.1, if it changes significantly with the storage refactor, >> that's fine, but I'd like to know if there was a reason for it in case >> we want to make it async for us. >> >> On Wed, Jun 5, 2013 at 7:21 PM, Marcus Sorensen <shadow...@gmail.com> >> wrote: >> > Just wondering why deleteVolume is a sync call. It doesn't seem to >> > adhere to the 'mark it removed, let a worker expunge it later after X >> > seconds' paradigm. I only noticed this when a storage system was >> > taking a bit to do the work and thus blocking the API call. >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™*
