Bug 1804669

Summary:	[RFE] Option "Destroy associated VM on host delete" should be disabled by default.
Product:	Red Hat Satellite	Reporter:	Waldirio M Pinheiro <wpinheir>
Component:	Hosts	Assignee:	Marek Hulan <mhulan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tstrych
Severity:	urgent	Docs Contact:
Priority:	high
Version:	6.7.0	CC:	akarimi, bbuckingham, inecas, mhulan, sokeeffe, wclark
Target Milestone:	6.9.0	Keywords:	EasyFix, FutureFeature, PrioBumpPM, Reopened
Target Release:	Unused
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Feature: Option "Destroy associated VM on host delete" should be disabled by default. Reason: People who delete the host were surprised by the fact, the VM was deleted and they lost the data. While this is desired behavior in public cloud environment, where running machines costs money, in private cloud or traditional virtualization environments, this could lead to serious damage. Therefore the default value for the setting is non-destructive. Result: The VM is not deleted upon host deletion by default.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-08-23 14:31:41 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 Waldirio M Pinheiro 2020-02-19 11:20:36 UTC

Description of problem:
This is really important, some times we get scenario where some content hosts were removed from vCenter after the customer just remove the CH from Satellite webUI. We already know the warning, however, the customer believes that will be related only to Satellite webUI. This feature is really interesting, however, should be disabled by default and once the customer is aware of how this work, they could switch easily.

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

How reproducible:
100%

Steps to Reproduce:
1. Configure the Compute Resource
2. Create a new VM
3. Delete the CH via Satellite webUI

Actual results:
The machine will be removed from vCenter (or external virtualization resource)

Expected results:
Remove only from Satellite side (db, webUI)

Additional info:

Comment 6 Marek Hulan 2020-02-25 16:29:14 UTC

Waldirio, this is what was discussed and agreed on in BZ 1549761, I think it works as expected. I'm closing as NOTABUG, please reopen if I misunderstood.

Comment 7 Waldirio M Pinheiro 2020-02-25 17:10:03 UTC

Yea, indeed.

Thank you my friend.

Waldirio

Comment 9 Marek Hulan 2020-06-30 09:19:18 UTC

Created redmine issue https://projects.theforeman.org/issues/30247 from this bug

Comment 10 Bryan Kearney 2020-07-04 20:03:33 UTC

Upstream bug assigned to mhulan

Comment 11 Bryan Kearney 2020-07-04 20:03:34 UTC

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/30247 has been resolved.

Comment 16 tstrych 2021-02-16 13:36:04 UTC

    Verified with 6.9.0 snap 13.0. 

    By default there is NO in Settings -> Provisioning -> Destroy associated VM on host delete
    In UI, when user is asked if he understands the action of not deleting machine from the virtualization resource. 

    When there is YES in settings -> user is also asked in UI if he understand the action and the machine together with disk will be removed.

Comment 17 Brad Buckingham 2021-08-23 14:31:41 UTC

This was verified on Satellite 6.9; therefore, moving the bugzilla to CLOSED:CURRENTRELEASE.

Comment 18 wclark 2021-11-15 16:22:25 UTC

Note that there are two relevant settings for subscription-manager unregister to result in VM deletion: destroy_vm_on_host_delete (on the 'Provisioning' tab in settings, the one referenced in this BZ) and also unregister_delete_host (on the 'Content' tab in settings, and defaults to 'false')

So in order for 'unregister' to delete a VM, both settings must be set true so that: sub-man unregister -> delete 'host' entry on satellite (due to unregister_delete_host true) -> destroy VM on compute resource (due to destroy_vm_on_host_delete true)

I still agree with setting destroy_vm_on_host_delete default to false as this BZ has done (because there are other ways to trigger accidental VM deletion without using sub-man unregister, and false is a much safer default), but making an additional note that any customers affected by this issue who saw this behavior specifically due to a subscription-manager unregister, should also check why unregister_default_host got changed from its default value of false and if that is what they really desire