Bug 1274095 - [RFE] Deleting object does not delete dependent objects [NEEDINFO]
[RFE] Deleting object does not delete dependent objects
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance (Show other bugs)
Unspecified Unspecified
medium Severity medium
: GA
: cfme-future
Assigned To: John Hardy
Dave Johnson
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2015-10-21 18:23 EDT by Thom Carlin
Modified: 2017-08-28 11:03 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-28 11:03:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
slukasik: needinfo? (gtanzill)

Attachments (Terms of Use)

  None (edit)
Description Thom Carlin 2015-10-21 18:23:53 EDT
Description of problem:

When removing an object (e.g. provider) from the VMDB, the dependent objects are not consistently deleted.

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

How reproducible:


Steps to Reproduce:
1. Define Infrastructure provider
2. Enter provider credentials
3. Refresh relationships and power states
4. Wait for relationships to be populated
5. Remove provider from VMDB
6. Examine Cluster/Host/VM/Datastores

Actual results:

Clusters are removed, others aren't

Expected results:

Either none are removed (and we document why) or all dependent objects are removed

Additional info:

Similarly for Cloud providers, hosts, etc.

This affects chargeback and may need to be an option.
Comment 4 Greg Blomquist 2016-02-19 16:31:53 EST
Gregg, can you verify the results from comment #3?  Is there a purge process that should be cleaning up orphaned objects as noted?  If so, how does it get scheduled?

Maybe this is just a doc bug?
Comment 5 Šimon Lukašík 2016-08-10 08:30:31 EDT
Hello Thom, thanks for report.

The behavior has been always this way. (Since 651e218558ce74b45d775a777c4afbea21aa664a, to be more specific).

I am trying to make my mind if this is correct or not. One can hardly tell.

On the one hand, when someone deletes a provider, s/he may want to purge all
the data and perhaps start over. I don't see what is the use-case of removing the provider, while keeping the (some) of the data read-only.

On the other hand, there is a value in keeping the data in.
 - There is a special state "orphaned" for Vms(or templates) that have no
   provider. At this state the UI allows you to review the valuable data you
   may have. I guess this might have been requested by users in past.
 - When you re-create the provider the VMs(and templates) that has been
   orphaned are correctly discovered and assigned to the re-crated provider.
 - All the control buttons are grey on orphaned entities, that leads me to
   think we have extra logic for this state.

Gregg, what are your thoughts? I imagine you may have much better view into what might be in the users heads when they hit the delete provider button.
Comment 6 Reartes Guillermo 2016-10-12 16:34:03 EDT

I my case i wanted to start over. I should be faster to delete the provider than to delete all tags from all objects.

Also, in that case, the vcenter was migrated from 5 to 6 (i found out after the fact) and i deleted the provider (vcenter5) and re-add it (vcenter6) and found, to my surprise that the tags survived.

So i had to re-tag everything. :-/

But since vcenter changed from v5 to v6 (same hosts and datastores) i really expected that deleting the provider would delete permanently its objects. (one can always re-add it).

Comment 8 Chris Pelland 2017-08-28 11:03:46 EDT
This bug has been open for more than a year and is assigned to an older release of CloudForms. 
If you would like to keep this Bugzilla open and if the issue is still present in the latest version of the product, please file a new Bugzilla which will be added and assigned to the latest release of CloudForms.

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