Hello Nik, On Fri, Jan 18, 2013 at 4:55 PM, Nik Martin <nik.mar...@nfinausa.com> wrote: > 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. >
Yep, it seems we don't have a choice for now. >> 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 expunged. We don't administrate the cloud. We are building an application that consumes CloudStack. We can't change the settings ourselves but we may ask for saner values. > 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. I don't think you understand what we are trying to achieve so please let me explain: We wish to create and destroy pools of virtual machines with a defined configuration (hardware, OS, installed packages and network access). This should be done automatic and reliable. Having networks as leftovers is not an option because next time we might not be able to create a new network (exceeded resource limits). Not being able to delete everything is a a limitation from our point of view. Let's hope we might achieve something by creating everything under a new account and deleting the account at the end. Thanks for the support so far, Cheers, >> >> 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] http://markmail.org/message/eeobo37hyqilya6g >> [2] http://download.cloud.com/releases/3.0.0/api_3.0.0/TOC_User.html >> [3] >> https://github.com/ieugen/axemblr-provisionr/blob/run-instance/providers/cloudstack/src/main/java/com/axemblr/provisionr/cloudstack/activities/DeleteNetwork.java >> [4] >> https://github.com/ieugen/axemblr-provisionr/blob/run-instance/providers/cloudstack/src/test/java/com/axemblr/provisionr/cloudstack/activities/EnsureNetworkExistsLiveTest.java >> >> > > > -- > > Regards, > > Nik > > Nik Martin > nfina Technologies, Inc. > +1.251.243.0043 x1003 > http://nfinausa.com > Relentless Reliability -- Ioan Eugen Stan / CTO / http://axemblr.com