Hi Aled and Andrew, The solution (reference [2]) provided by Aled works great - it deleted all the jclouds related keypairs and security groups.
Thanks, -Liang On Sat, Jan 3, 2015 at 11:33 PM, liang cheng <[email protected]> wrote: > Hi Aled, > > Thank you so much. I'll give it a try. > > -Liang > > On Sat, Jan 3, 2015 at 5:55 AM, Aled Sage <[email protected]> wrote: > >> Hi Liang, >> >> I presume you are just doing a "destroy", with that automatically trying >> to delete the security group (rather than an explicit deleteSecurityGroup >> by you)? >> >> This bug is reported in [1]. >> >> There are instructions for how to delete the old security groups and >> key-pairs at [2]. >> >> --- >> There seems to be eventual consistency within EC2 for when the security >> group is no longer in use. After terminating the VM, it can take anywhere >> from immediate to several minutes before an attempted deletion of the >> security group will succeed (it fails if it thinks there is still a VM >> using the security group). jclouds does a retry 3 times to delete it, but >> it doesn't wait for several minutes. >> >> An alternative could be: on delete, query EC2 to find the VMs using the >> security group, and then query those VMs' states to see if they are not >> termianted (or short-cut that if we know we currently deleting the only VM >> in that list) - we could then keep trying for 5 or 10 minutes. But that >> doesn't sound ideal either. >> >> Aled >> >> [1] https://issues.apache.org/jira/browse/JCLOUDS-207 >> [2] http://www.cloudsoftcorp.com/blog/2013/03/tidying-up-after-jclouds/ >> >> >> >> On 03/01/2015 11:19, Andrew Phillips wrote: >> >>> Hi Liang >>> >>> Is this behaviour reproducible, i.e. does it happen every time you run >>> the example? If you add some wait time to the example code between the >>> moment it destroys the node and tries to delete the security group, do you >>> get the same result? >>> >>> Regards >>> >>> ap >>> >> >> >
