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:
Bill - Please review, let me know if this should go to the providers team.
*** This bug has been marked as a duplicate of bug 1468635 ***
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.
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.
PR to bump azure-armrest version: https://github.com/ManageIQ/manageiq-providers-azure/pull/154