Bug 1437549 - containers: objects from previous providers remain in setup after provider delete
Summary: containers: objects from previous providers remain in setup after provider de...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.8.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: GA
: 5.9.0
Assignee: Ari Zellner
QA Contact: Einat Pacifici
URL:
Whiteboard: container
: 1417150 1437558 1465934 (view as bug list)
Depends On:
Blocks: 1478802
TreeView+ depends on / blocked
 
Reported: 2017-03-30 14:03 UTC by Dafna Ron
Modified: 2018-10-17 18:03 UTC (History)
15 users (show)

Fixed In Version: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-01 13:11:02 UTC
Category: ---
Cloudforms Team: Container Management
Target Upstream Version:


Attachments (Terms of Use)
logs and screenshots (5.97 MB, application/x-gzip)
2017-03-30 14:03 UTC, Dafna Ron
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0380 normal SHIPPED_LIVE Moderate: Red Hat CloudForms security, bug fix, and enhancement update 2018-03-01 18:37:12 UTC

Description Dafna Ron 2017-03-30 14:03:45 UTC
Created attachment 1267573 [details]
logs and screenshots

Description of problem:

I did a test of adding/deleting the same provider several times and although the provider has been removed the objects are still presented in the setup. 
(see screenshots)

Version-Release number of selected component (if applicable):
cfme-5.8.0.8-alpha1.1.el7cf.x86_64

How reproducible:

100%
Steps to Reproduce:
1. deploy cfme
2. Add the provider to cfme -> refresh to make sure the objects in the cluster are added
3. remove the provider 
4. repease step 2 and 3 several times

Actual results:

The provider is removed but we are seeing all the objects from each time we added the provider

Expected results:

all objects should be cleared and we should not remove the provider object until all sub-objects are cleaned (i.e images, nodes, volumes atc) 

Additional info:
logs and screenshots

Comment 1 Greg Blomquist 2017-03-30 15:25:46 UTC
Dafna, this might be expected behavior.  Are the objects marked as orphaned or archived?

Comment 2 Barak 2017-04-03 09:45:18 UTC
Did those objects remain indefinitely?

There are some objects that should remain ,
However this also may be related to Bug#1436132

Not closing yet.

Comment 3 Dafna Ron 2017-04-03 10:14:28 UTC
They are still there. 
Please contact me off line if you want access to my setup to try and determine if it is related to 1436132.

Comment 4 Federico Simoncelli 2017-04-03 12:40:16 UTC
This seems a duplicate of bug 1322601.

Ari I am not sure if this is a bug or not (see comment 1) anyway you looked into bug 1322601 and you can work with Dafna to check what's going on here.

Lowering severity from urgent to high because I don't expect to have frequent scenarios where an user would continuously add and remove the same provider.

Comment 5 Ari Zellner 2017-04-03 12:51:06 UTC
This is the exact scenario as in https://bugzilla.redhat.com/show_bug.cgi?id=1369359

The problem is the endless refreshes together with deleting the provider
meaning the real problem is endless refreshes(which we are handling somewhere else).
Ill try to solve this with https://github.com/ManageIQ/manageiq/pull/13204 .
It wont stop the endless refreshes but itll solve this symptom.

Comment 6 Ari Zellner 2017-04-03 13:12:52 UTC
Dafna, to verify this is the same problem you can try to turn off the automation engine through the settings page and then reproduce the problem. It shouldnt happen when the automation engine is off.

Comment 7 Dafna Ron 2017-04-05 09:42:31 UTC
(In reply to Ari Zellner from comment #6)
> Dafna, to verify this is the same problem you can try to turn off the
> automation engine through the settings page and then reproduce the problem.
> It shouldn't happen when the automation engine is off.

I reproduced after removing the automate but I added a tiny detail which is to manually sync the provider after adding it so that we add the objects. 

so the reproduction steps are: 

1. disable automate
2. add a provider
3. initiate manual sync for the provider
4. remove the provider -> reload page until provider disappears from provider's page
5. add the same provider 
6. initiate manual sync for the provider
7. once provider is synced -> navigate to compute -> pods -> providers

I can still see the objects from the previous provider. 

I think that there is a secondary issue with the sync of the actual menu pages because I also did a second test where I navigated to the pods's page after removing the provider and all the pods disappeared. so I think there is some sort of table in the db that is not cleaned properly when removing the provider.

Comment 8 Ari Zellner 2017-04-06 12:01:33 UTC
Im having trouble reproducing but from your description it looks like this will happen not just when there are lots of refreshes but in any case where a refresh and delete of the same provider are racing against each other.
Im looking into this.

Comment 13 Mooli Tayer 2017-06-13 14:14:16 UTC
Do we plan to backport these PRs to fine? (including migration)

Comment 14 Greg Blomquist 2017-07-24 17:18:14 UTC
*** Bug 1417150 has been marked as a duplicate of this bug. ***

Comment 15 Federico Simoncelli 2017-08-01 21:31:50 UTC
(In reply to Mooli Tayer from comment #13)
> Do we plan to backport these PRs to fine? (including migration)

No.

Comment 16 Mooli Tayer 2017-08-02 08:47:28 UTC
POST?

Comment 17 Federico Simoncelli 2017-09-22 09:11:36 UTC
*** Bug 1437558 has been marked as a duplicate of this bug. ***

Comment 20 errata-xmlrpc 2018-03-01 13:11:02 UTC
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/RHSA-2018:0380

Comment 21 Sam Lucidi 2018-10-17 18:03:08 UTC
*** Bug 1465934 has been marked as a duplicate of this bug. ***


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