Bug 1274095 - [RFE] Deleting object does not delete dependent objects
Summary: [RFE] Deleting object does not delete dependent objects
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.4.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: cfme-future
Assignee: John Hardy
QA Contact: Dave Johnson
URL:
Whiteboard: database:retest
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-21 22:23 UTC by Thom Carlin
Modified: 2021-06-10 20:13 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-28 15:03:46 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Thom Carlin 2015-10-21 22:23:53 UTC
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):

5.4.3.1

How reproducible:

100%

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 21:31:53 UTC
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 12:30:31 UTC
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 20:34:03 UTC
Hi,

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).

Cheers.

Comment 8 Chris Pelland 2017-08-28 15:03:46 UTC
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.