Bug 1497175

Summary:	managed disks are not removed as part of azure stack retirement
Product:	Red Hat CloudForms Management Engine	Reporter:	Felix Dewaleyne <fdewaley>
Component:	Automate	Assignee:	Bill Wei <bilwei>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Dave Johnson <dajohnso>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.8.0	CC:	bilwei, dberger, fdewaley, gekis, gmccullo, jhardy, mkanoor, obarenbo, simaishi, smallamp, tfitzger
Target Milestone:	GA	Keywords:	Reopened, TestOnly
Target Release:	5.10.0
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	5.10.0.0	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1510173 1510175 (view as bug list)		Environment:
Last Closed:	2018-06-21 20:37:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1510173, 1510175

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