Bug 1549761

Summary: [RFE] Flag to avoid deletion from compute resource of an host associated when it's removed from satellite
Product: Red Hat Satellite Reporter: Andrea Perotti <aperotti>
Component: Compute ResourcesAssignee: Marek Hulan <mhulan>
Status: CLOSED ERRATA QA Contact: Lukáš Hellebrandt <lhellebr>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.3.0CC: ahumbe, bbuckingham, bkearney, cdonnell, cmarinea, dchaudha, dyuen, fgarciad, green, ktordeur, lhellebr, mhulan, oprazak, pdudley, rjerrido, rraghuwa, stefan.heijmans, tasander, zhunting
Target Milestone: 6.5.0Keywords: FutureFeature, PrioBumpField, PrioBumpGSS, PrioBumpPM
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: foreman-1.20.1.4-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-14 12:37:00 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:
Bug Depends On:    
Bug Blocks: 1541321    

Description Andrea Perotti 2018-02-27 18:59:39 UTC
1. Proposed title of this feature request
Avoid the accidental Virtual Machines deletion from the compute resources when associated Host profile is deleted in Sat6 by setting a global configurable flag.

3. What is the nature and description of the request? 
When a VM from a compute resource is registered into satellite, is linked to his host profile.

In consequence of that, if that host is deleted from Satellite, is deleted from the compute resource as well.

The request is to have a flag to avoid this behavior, but to maintain association, in order to be able to work and edit the host configuration (like puppet modules and so on).

4. Why does the customer need this? (List the business requirements here)
This feature is needed in order to avoid to have to de-associate VMs to prevent accidental VMs deletion.


5. How would the customer like to achieve this? (List the functional requirements here)

An option in foreman like:

delete_resource_on_host_removal

by default could be kept to true, to maintain the usual behaviour, but optionally this could be set to false, and change the behaviour.

6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

a) activate the flag
b) delete and host profile
c) ensure the VM remain active and existent

8. Does the customer have any specific timeline dependencies?
The sooner the better: currently the UX of the customer with the product is highly impacted by this.

9. Is the sales team involved in this request and do they have any additional input?
no 

11. Would the customer be able to assist in testing this functionality if implemented?
Yes, sure

Comment 3 Marek Hulan 2018-03-01 06:42:50 UTC
Created redmine issue http://projects.theforeman.org/issues/22737 from this bug

Comment 11 Rich Jerrido 2018-10-04 15:38:26 UTC
Marking bz1634114 as a dupe of this BZ. There are two use-cases we need to solve for:


1 - As a user, if I interactively delete a host record, I should (have the option to) be prompted if it is associated with a virtual machine.

2 - As a user, if I delete a host record via hammer/API, I should have the option to be force deletion of both the host record and virtual machine.

Comment 12 Rich Jerrido 2018-10-04 15:38:41 UTC
*** Bug 1634114 has been marked as a duplicate of this bug. ***

Comment 15 Satellite Program 2018-10-08 22:04:58 UTC
Upstream bug assigned to mhulan

Comment 16 Satellite Program 2018-10-08 22:05:01 UTC
Upstream bug assigned to mhulan

Comment 23 Satellite Program 2018-10-12 14:05:06 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/22737 has been resolved.

Comment 27 orabin 2018-11-19 14:19:00 UTC
*** Bug 1650680 has been marked as a duplicate of this bug. ***

Comment 32 Lukáš Hellebrandt 2018-12-19 11:24:41 UTC
I don't think the description in settings makes sense:
"Destroy associated VM on host delete. When enabled, VMs linked to Hosts will be deleted on Compute Resource, meaning they can be re-associated or imported back to Satellite again. This does not automatically power off the VM"

This may have been caused by changing "Disassociate VMs before Host deletion" to "Destroy associated VM on host delete" which has opposite meaning and uncarefully editing the description.

Comment 33 Lukáš Hellebrandt 2018-12-19 12:57:32 UTC
When deleting a host with the flag set to true, a confirmation dialogue informing about VM deletion is correctly displayed. However, when bulk-deleting hosts, the confirmation dialogue is NOT displayed and the VMs are deleted immediately.

Comment 34 Marek Hulan 2018-12-19 13:25:36 UTC
The finding in comment 33 is IMHO out of the scope for this bug. The scope was described in comment 17. This is not regression introduced by this change AFAIK. Given you can select multiple hosts that are virtual or not, the message would have to be too generic. Lukáš, if you want this to be changed, please open a separate RFE, it should not block this BZ.

Comment 41 Lukáš Hellebrandt 2019-01-17 09:40:12 UTC
Marek, do we want this warning to also appear in Hammer? I suppose not but asking just to be sure we only want this in WebUI.

Comment 42 Marek Hulan 2019-01-17 16:28:23 UTC
If you had interactive confirmation in mind, that would feel inconsistent with other destructive operations. I'd say yes to make it part of help output, but only in generic form, hammer shouldn't change help based on server configuration I think. If you'd like to see that, I'd track under separate RFE, to no longer block this feature.

Comment 43 Lukáš Hellebrandt 2019-01-18 10:32:11 UTC
I agree.

VERIFIED this on Sat 6.5 snap 11.

Deleting a host (even in bulk operation) that has a VM associated now warns that it will delete the VM, too, and points to the settings where this behavior can be changed. When it is changed, the warning changes, saying it will not delete the VM.

Comment 44 Marek Hulan 2019-01-28 11:27:16 UTC
*** Bug 1504267 has been marked as a duplicate of this bug. ***

Comment 47 errata-xmlrpc 2019-05-14 12:37:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:1222