Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1497175 - managed disks are not removed as part of azure stack retirement
Summary: managed disks are not removed as part of azure stack retirement
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.8.0
Hardware: All
OS: All
medium
medium
Target Milestone: GA
: 5.10.0
Assignee: Bill Wei
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks: 1510173 1510175
TreeView+ depends on / blocked
 
Reported: 2017-09-29 11:51 UTC by Felix Dewaleyne
Modified: 2018-06-21 20:37 UTC (History)
11 users (show)

Fixed In Version: 5.10.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1510173 1510175 (view as bug list)
Environment:
Last Closed: 2018-06-21 20:37:23 UTC
Category: ---
Cloudforms Team: ---


Attachments (Terms of Use)

Description Felix Dewaleyne 2017-09-29 11:51:20 UTC
Description of problem:
storage not removed as part of azure stack retirement

Version-Release number of selected component (if applicable):
5.8.1.5

How reproducible:
all the time

Steps to Reproduce:
1. use the default retirement automate to retire an azure ressource
2.
3.

Actual results:
storage is left behind

Expected results:
storage is also retired

Additional info:

Comment 4 Greg McCullough 2017-09-29 12:09:50 UTC
Bill - Please review, let me know if this should go to the providers team.

Comment 9 Greg McCullough 2017-10-10 10:55:33 UTC

*** This bug has been marked as a duplicate of bug 1468635 ***

Comment 10 Bill Wei 2017-10-16 20:17:32 UTC
This issue may not be a duplicate of bug 1468635. For this issue resources (vm and nic) for the stack other than storage were removed in the process of retirement.

We make our best efforts to delete associated resources. But if one of the deletion fails we will ignore the failure and continue because the stack is already partially deleted and cannot be rolled back. 

The argument here is how do we know the retirement completes with or without any error. The deletion of resources of a stack is done in armrest library, not controlled by automation. From the source code in https://github.com/ManageIQ/azure-armrest/blob/master/lib/azure/armrest/template_deployment_service.rb#L54 we can see the errors are logged in azure.log. The error is not propagated back to the caller. This is something we can probably enhance.

Please examine azure.log for the actual reason why disk could not be deleted. In armrest library we already retry a few times to delete. In reality resource can be left not deleted if for example it was in use.

Comment 16 Bill Wei 2017-11-01 19:45:34 UTC
Our Azure stack retirement first tries to delete all resources reported by the stack. In the provided log I saw it deleted VM, NIC, Storage Account, and finally the stack itself. 

There was no attempt to delete managed disks because they were not reported as the resources of the stack. According the warnings in https://docs.microsoft.com/en-us/azure/storage/common/storage-create-storage-account, the managed disks should be deleted by deleting the storage account.

The real problem in the provided log was the failure to delete the stack itself. We have identified the cause and fixed by
https://github.com/ManageIQ/azure-armrest/pull/347

Once it is included in next azure-armrest release and updated in manageiq-providers-azure, we can retest the retirement of Azure stack.

Comment 17 Satoe Imaishi 2017-11-06 20:44:05 UTC
PR to bump azure-armrest version: https://github.com/ManageIQ/manageiq-providers-azure/pull/154


Note You need to log in before you can comment on or make changes to this bug.