Bug 1480577 - Removing OpenStack Cloud provider doesn't delete network data from database
Removing OpenStack Cloud provider doesn't delete network data from database
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers (Show other bugs)
Unspecified Unspecified
high Severity high
: GA
: cfme-future
Assigned To: Gilles Dubreuil
Ola Pavlenko
Depends On:
  Show dependency treegraph
Reported: 2017-08-11 08:23 EDT by Patrik Holop
Modified: 2017-12-05 10:12 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-09-06 07:29:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: Bug
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: Openstack

Attachments (Terms of Use)
Screenshot of duplicated entities (83.50 KB, image/png)
2017-08-11 08:23 EDT, Patrik Holop
no flags Details

  None (edit)
Description Patrik Holop 2017-08-11 08:23:09 EDT
Created attachment 1312117 [details]
Screenshot of duplicated entities

Description of problem:
After removing OpenStack cloud provider, all network information except network providers are still in the database.

Version-Release number of selected component (if applicable):
downstream 58-z

How reproducible:

Steps to Reproduce:
1. Add OpenStack cloud provider
2. Navigate to Networks->Providers, Networks->Subnets etc. and
   check added data
3. Remove OpenStack cloud provider
4. Check network data once again

Actual results:
1. All network data except network providers are still in the database
2. From other entities like subnets and routers disappeared Network Manager 
3. Networks->Topology should display network data, if they are in database

Expected results:
1. All network data should disappear with removing cloud provider
2. Other entities should disappear with network provider entirely, not just
   one relationship
3. No network data are shown in Networks->Topology

Additional info:
1. Topology can't display the data correctly, because root object "network 
   provider" for them no longer exists in the database.
2. After adding OpenStack provider once again, other entities like subnets and 
   routers were duplicated (one with and one without network manager)
Comment 2 Tzu-Mainn Chen 2017-08-14 10:23:32 EDT
Gilles, could you take a look at this one?
Comment 3 Gilles Dubreuil 2017-08-23 22:36:27 EDT

Unfortunately, I haven't been able to reproduce the same symptoms on manageiq/fine (5.8.x) branch.

The closest I've obtained is, after multiple tests, I've seen a couple of times a delay to occur where the networks are not yet removed. This is caused by the delete task being delayed as the task is running in the background in async mode.

Could you please verify and test latest version of 5.8.x? 

Comment 4 Patrik Holop 2017-08-29 10:48:48 EDT

sorry for the late response, I was on vacation and I'm a bit busy right know, but tomorrow I'll take a look at it and retest it. 

Comment 5 Patrik Holop 2017-08-30 05:09:19 EDT

I was able to reproduce this bug with automated tests (still in dev, repo integration_tests PR #5133). If I added providers this way

pytest_generate_tests = testgen.generate(
    classes=[AzureProvider, EC2Provider, OpenStackProvider], scope='module')
pytestmark = pytest.mark.usefixtures('setup_provider')
which automatically and successfully added those providers,
manually checking the cloud provider and selecting 
configuration->remove Cloud Providers
after test run caused this bug again.

In my testing appliance are other network entities still there after half an hour, which would be a quite long delay.

Patrik Holop
Comment 6 Gilles Dubreuil 2017-09-05 23:29:04 EDT
Hi Patrik,

I understand you're facing the issue on aforementioned PR#5133 meanwhile I believe that repo gets updates from downstream.

Would you be able to verify against latest Fine branch?

Comment 7 Patrik Holop 2017-09-06 07:06:37 EDT
Few more times I wasn't able to reproduce the bugs either.

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