jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignasi Barrera (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:38:24 GMT

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

Ignasi Barrera commented on JCLOUDS-1230:
-----------------------------------------

I will add the commits in there to the SecurityGroupExtension PR.

One of the caches I've created is to get a resource group for a given location, and using
it avoids many errors when the resource group does not exist. For example if you use the SG
extension to create firewalls before you create any node; in that case the resource group
could not exist and the current code of the extension would fail. The same happens in many
places in the code where we assume the resource group always exists.

I'm running the tests now and will push all the changes to that PR branch. it will contain
lots of changes, because I've done a significant cleanup there (remove unused custom template
options, removed useless constants class that duplicated timeout and polling properties, etc).

I'll ping you once everything is uploaded so you can review and test it too.

> 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