Red Hat Bugzilla – Bug 1437549
containers: objects from previous providers remain in setup after provider delete
Last modified: 2018-10-17 14:03:08 EDT
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
Dafna, this might be expected behavior. Are the objects marked as orphaned or archived?
Did those objects remain indefinitely? There are some objects that should remain , However this also may be related to Bug#1436132 Not closing yet.
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.
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.
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.
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.
(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.
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.
Upstream PRs: https://github.com/ManageIQ/manageiq/pull/14675 - migration and disable https://github.com/ManageIQ/manageiq/pull/14848 - wait for ems https://github.com/ManageIQ/manageiq/pull/15339 - fix
Do we plan to backport these PRs to fine? (including migration)
*** Bug 1417150 has been marked as a duplicate of this bug. ***
(In reply to Mooli Tayer from comment #13) > Do we plan to backport these PRs to fine? (including migration) No.
POST?
*** Bug 1437558 has been marked as a duplicate of this bug. ***
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
*** Bug 1465934 has been marked as a duplicate of this bug. ***