Bug 1788053

To clarify the issue, is the retirement for an orchestration service, an azure instance or azure stack?
Thanks.

Hello,

The object that is being retired is an individual VM.

Thanks!

If memory serves, we didn't delete storage by default because we planned on adding a storage manager that would let you manage the storage/disks separately, but that never materialized. So, we didn't delete storage (or network security groups) by default.

As per discussion with Lucy, I -think- it might be a matter of updating this line:

  https://github.com/ManageIQ/manageiq-providers-azure/blob/master/app/models/manageiq/providers/azure/cloud_manager/vm/operations.rb#L9

To this:

  provider_service.delete_associated_resources(name, resource_group.name, :storage_account => true)

Actually, after thinking about this overnight, I think I remember why we don't delete the disk. The issue is that storage can be shared by multiple VM's. So, like Azure itself, we don't delete the associated storage when a VM is deleted.

Now, I'm pretty sure a deletion attempt would fail if there is anything else attached to it, so we could try to delete it and, if it fails, just log and/or raise an error. But, this is something that needs to be discussed.

Tested azure VM provision and service provision with 5.10.10.0.
  VM was provisioned in both cases.

Tested VM/instance retirement and service retirement. 
  Disk was removed from azure portal in both cases.
  VM was archived for both cases.
  Service was retired for 2nd case.

So the disk was removed when VM got retired. Can't reproduce the issue locally.

1. How often does the customer run into the issue? 
2. Is there any customized code in automate? Does it work if all customized automate code is disabled?

If it still fails with all customization code disabled, please send us the following information
1. the screen shots of the VM state before and after the retirement
2. the screen shot of the failed request
3. complete set of logs showing how the request was created, and showing the failure.

From the log files, the customer did service provisioning and service retirement, not an individual VM as stated in comment #3.

Local tests of service retirement with 5.10.10 works well. 

[----] I, [2020-01-14T14:09:53.415149 #3872:fe0f60]  INFO -- : Q-task_id([r1000000000404_service_retire_task_1000000000410]) Invoking [inline] method [/IAAS/Service/Retirement/StateMachines/Methods/retire_service] with inputs [{}]

Customer used customized code in domain /IAAS which might have caused the issue. 

Please test with all customized automate code disabled.

If it fails, please send us the following information.
1. the screen shots of the service state before and after the retirement
2. the screen shot of the failed service request
3. complete set of logs showing how the request was created, and showing the failure.

Thanks.

This sounds like an Azure disks add/remove issue instead of an automate retirement issue.
Forward the BZ to provider team for debugging. 
Please return back the BZ if I'm wrong here. 
Thanks.

Alright, my memory was playing tricks on me. We DO delete the OS disk by default for managed storage, but currently the azure-armrest gem doesn't delete attached data disks.

I will have to update the azure-armrest gem, then integrate that change into the core code.

https://github.com/ManageIQ/manageiq-providers-azure/pull/377

New commit detected on ManageIQ/manageiq-providers-azure/ivanchuk:

https://github.com/ManageIQ/manageiq-providers-azure/commit/cfeeb130051bb6aa5875bec40cc98822f0a5dcd1
commit cfeeb130051bb6aa5875bec40cc98822f0a5dcd1
Author:     Adam Grare <agrare>
AuthorDate: Fri Jan 24 18:36:19 2020 +0000
Commit:     Adam Grare <agrare>
CommitDate: Fri Jan 24 18:36:19 2020 +0000

    Merge pull request #377 from djberg96/attached_disks

    Delete attached data disks on vm destroy

    (cherry picked from commit d67792c0c4d2b333c0e78e91c8099a53af6e0686)

    https://bugzilla.redhat.com/show_bug.cgi?id=1788053

 app/models/manageiq/providers/azure/cloud_manager/vm/operations.rb | 2 +-
 manageiq-providers-azure.gemspec | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

I created a two VMs and attached a volume (managed disk) to each.

I retired a VM using these CFME version appliances

5.11.5.1.20200415152414_39b433a
5.11.4.2.20200309205646_632ff59

The disk of VM retired with the newer version was removed
The disk of VM retired with the older version was not removed.

I am not sure this is a good idea, but it works as customer expects.

Should this happen for volumes on OpenStack and other Cloud providers as well?

Jaroslav, I don't know. This would have to be discussed either in the individual provider channels, or the core channel. If so, separate issues should be created for each provider.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2020