cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nik Martin <>
Subject Re: force expunge
Date Fri, 18 Jan 2013 14:55:15 GMT
On 01/18/2013 04:41 AM, Ioan Eugen Stan wrote:
> Hello Nik, Ahamad,
> I've asked on the list what API implementation to use [1] . From my
> experience, when working with API's you end up writing a client. So if
> one is already provided I choose to use that. It tends to be tested
> and makes development easy and the code maintainable. Nobody wants
> code that's hard to maintain. I could add a few more arguments but
> it's not the point.
I guess my point of asking is you really don't need an API client to 
talk to the CS API, it is drop dead simple.

> Regarding the expunge time, I've tested with a cloud that kept
> machines in 'Destroyed' state for as long as 20 minutes or more. I
> never stayed so long as to see how long, but the idea is that I can't
> clean up networks and maybe other stuff in that time. This is not
> something that you would like when you wish to automate stuff around
> CloudStack.  You NEED to be able clean on demand.
Have you found the TWO parameters that affect expunge time? they are 
1800 secs by default: expunge.delay and expunge.interval.  Also, 
expunge.workers is how many expunge threads to run at a time. If you set 
both of those to 10 and have sufficient expunge workers, the vms will be 

Unfortunately, you may need to adopt Cloudstack's "lazy" way of cleaning 
up, which is to create a scheduled task that goes through and cleans up 
every hour or so.  The lack of VMs in an account is not a reason to 
delete the network, unless you are also trying to delete the account 
along with it.
> Ahamad: I'm using [2] fot documentation. I have tests that create and
> delete[3] networks and work fine [4]. The network does not get deleted
> when there are VM's associated with it. The delete network operation
> fails, the VM's can be destroyed, or expunging, it doesn't matter.
> Cheers,
> [1]
> [2]
> [3]
> [4]




Nik Martin
nfina Technologies, Inc.
+ x1003
Relentless Reliability

View raw message