jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrea Turli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-1230) azurecompute-arm: VM deletion takes very long time (many extra api calls?)
Date Thu, 26 Jan 2017 11:24:24 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839582#comment-15839582
] 

Andrea Turli commented on JCLOUDS-1230:
---------------------------------------

thanks [~nacx], please open a PR for that as I want to improve CleanupResources as described
above.


> azurecompute-arm: VM deletion takes very long time (many extra api calls?)
> --------------------------------------------------------------------------
>
>                 Key: JCLOUDS-1230
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1230
>             Project: jclouds
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: Aled Sage
>            Assignee: Andrea Turli
>
> Deleting a VM in azurecompute-arm took 5mins 55seconds. Looking at the logging for that
thread, I suspect there are a lot of optimisations that could be done.
> Here's a rough breakdown of the destroy steps, and how long they take:
> * Get details of the VM and other pieces (e.g. network interface, etc  
>   3 seconds
> * List all the images  
>   11 seconds
> * List all the storageaccounts  
>   3mins 39secs
> * List providers/locations  
>   1 second
> * Delete the VM, and poll for completion . 
>   1min 51secs
> * Delete nic  
>   3 seconds
> * Delete VM disk storage  
>   1 second
> * delete storage account  
>   4 seconds
> Can we avoid listing all the images and all the storage?
> Below are some log snippets that illustrate this (all taken from a single thread):
> {noformat}  
> 2017-01-25 16:01:44,266 DEBUG 106 j.compute [ger-M9fVKLUG-247] >> destroying node(southeastasia/qa-entity-id-ca)
> ... 
> 2017-01-25 16:01:44,267 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking GetVirtualMachine
> ... 
> 2017-01-25 16:01:47,859 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking sku:list
> ... 
> 2017-01-25 16:01:58,598 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking resourcegroup:list
> ... 
> 2017-01-25 16:01:58,628 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking storageaccount:list
> ... 
> 2017-01-25 16:05:37,543 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking providers:get
> ...
> 2017-01-25 16:05:37,592 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking location:list
> ...
> ...
> 2017-01-25 16:05:38,916 DEBUG 106 j.compute [ger-M9fVKLUG-247] >> destroying southeastasia/qa-entity-id-ca
...
> 2017-01-25 16:05:38,917 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking DeleteVirtualMachine
> ...
> 2017-01-25 16:07:29,170 DEBUG 106 j.compute [ger-M9fVKLUG-247] >> destroying nic
jc-nic-qa-entity-id-ca...
> 2017-01-25 16:07:29,171 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking networkinterfacecard:delete
> ...
> 2017-01-25 16:07:32,091 DEBUG 106 j.compute [ger-M9fVKLUG-247] >> deleting public
ip nic public-address-qa-entity-id-ca...
> 2017-01-25 16:07:32,091 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking publicipaddress:delete
> ...
> 2017-01-25 16:07:34,107 DEBUG 106 j.compute [ger-M9fVKLUG-247] >> deleting virtual
machine disk storage...
> 2017-01-25 16:07:34,121 DEBUG 101 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking DeleteContainer
> ...
> 2017-01-25 16:07:35,141 DEBUG 106 j.compute [ger-M9fVKLUG-247] >> deleting storage
account qaentityid524b...
> 2017-01-25 16:07:35,142 DEBUG 106 o.j.r.i.InvokeHttpMethod [ger-M9fVKLUG-247] >>
invoking storageaccount:delete
> ...
> 2017-01-25 16:07:39,855 DEBUG 106 j.compute [ger-M9fVKLUG-247] << destroyed node(southeastasia/qa-entity-id-ca)
success(true)
> {noformat}
> Also, combined with https://issues.apache.org/jira/browse/JCLOUDS-1229 this could be
very dangerous: we might well be rate-limited while trying to list all the images and thus
the VM deletion / cleanup would be aborted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message