Bug 1274095

Summary:	[RFE] Deleting object does not delete dependent objects
Product:	Red Hat CloudForms Management Engine	Reporter:	Thom Carlin <tcarlin>
Component:	Appliance	Assignee:	John Hardy <jhardy>
Status:	CLOSED WONTFIX	QA Contact:	Dave Johnson <dajohnso>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.4.0	CC:	abellott, greartes, gtanzill, hkataria, jfrey, jhardy, mpovolny, obarenbo, slukasik, tcarlin
Target Milestone:	GA	Keywords:	FutureFeature
Target Release:	cfme-future
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	database:retest
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-28 15:03:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.