Bug 1417150 - Refreshing aws provider and then deleting makes provider items not deleted
Summary: Refreshing aws provider and then deleting makes provider items not deleted
Keywords:
Status: CLOSED DUPLICATE of bug 1437549
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.9.0
Assignee: Marcel Hild
QA Contact: Matouš Mojžíš
URL:
Whiteboard: provider:ec2:ui
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-27 10:06 UTC by Matouš Mojžíš
Modified: 2017-12-07 15:00 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-24 17:18:14 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)
evm.log (10.39 MB, text/plain)
2017-03-14 20:26 UTC, Matouš Mojžíš
no flags Details
aws.log (2.40 KB, text/plain)
2017-03-14 20:28 UTC, Matouš Mojžíš
no flags Details

Description Matouš Mojžíš 2017-01-27 10:06:49 UTC
Description of problem:


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

How reproducible:
Always

Steps to Reproduce:
1. Add an ec2 provider
2. Wait for full refresh and then do refresh again
3. Immediately after that delete provider

Actual results:
Items like VMs/key pairs and other are not deleted from vmdb.

Expected results:
Items should be deleted.

Additional info:

Comment 2 Greg Blomquist 2017-02-02 15:01:43 UTC
Matouš, do the items show up as archived?  If so, then it's working as designed.

MIQ doesn't delete objects like VMs when a provider is deleted because of the overhead of deleting related records like Metrics and Events.

Comment 3 Matouš Mojžíš 2017-02-02 17:05:01 UTC
How can I find out whether it's archived?
For example when I do this and add another ec2 provider and try to provision an instance then I have all the images twice in image selection. I think this is not how it should be.

Comment 4 Marcel Hild 2017-03-14 13:28:27 UTC
I'm pretty sure this is a race condition.
We should schedule the delete of a provider.

https://github.com/ManageIQ/manageiq/pull/13204 evaluates this approach.

Matouš can you do this again and attach all logs to this BZ?

related BZs
https://bugzilla.redhat.com/show_bug.cgi?id=1369359
https://bugzilla.redhat.com/show_bug.cgi?id=1343328

Comment 5 Matouš Mojžíš 2017-03-14 20:26:20 UTC
Created attachment 1263043 [details]
evm.log

Comment 6 Matouš Mojžíš 2017-03-14 20:27:45 UTC
Whole evm.log, fresh appliance and I only added, refreshed, deleted ec2 provider. Version 5.7.1.3.
Also aws log attached.

Comment 7 Matouš Mojžíš 2017-03-14 20:28:08 UTC
Created attachment 1263044 [details]
aws.log

Comment 8 Marcel Hild 2017-07-18 08:48:18 UTC
reading the logs, this is indeed because the destroy of the provider was running at the same time as a refresh and thus was creating inventory (templates) while deleting it leaving disconnected entities.

since https://github.com/ManageIQ/manageiq/pull/14848 we have an orchestrated destroy, which waits for all workers to stop and then does the destroy.

Matouš I just checked with a current upstream appliance and it worked as expected.
The only "issue" I had was, that I needed to explicitly destroy the dependent Network and storage managers. 
After that, the cloud manager got destroyed and left no templates or vms.

Ok to close this?

Comment 9 Greg Blomquist 2017-07-24 17:18:14 UTC
Dup'ing this on bug #1437549.  I know this one is older, but that one has more details about the fix and is tracking the relevant PRs.

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


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