Bug 1874480

Summary:	[Common templates] Deletion of running VM - VMI may be deleted long after the VM; foregroundDeletion should be added to the templates
Product:	Container Native Virtualization (CNV)	Reporter:	Ruth Netser <rnetser>
Component:	SSP	Assignee:	Karel Šimon <ksimon>
Status:	CLOSED CANTFIX	QA Contact:	Israel Pinto <ipinto>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	2.4.1	CC:	cnv-qe-bugs, fdeutsch, oyahud, rmohr
Target Milestone:	---
Target Release:	2.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-14 15:04:58 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 Ruth Netser 2020-09-01 13:12:17 UTC

Description of problem:
With the updated templates; terminationGracePeriod is 180 for Linux-based OS and 3600 for Windows.
When a running VM is deleted, it may take up to terminationGracePeriod for the VMI to be deleted. In that period of time the VM is removed from the UI (and CLI) and there's no indication for the user that the VMI is still running.
Switching blocking-VM-deletion-behaviour to foregroundDelete will keep the VM as long as the VMI still exists.

(bug 1873402)


How reproducible:
100% is the VMI is not imediately removed as well (VMI deletion duration may vary)

Steps to Reproduce:
1. Create Windows VM
2. Start the VM
3. Delete the VM

Actual results:
VM is not available in the UI/CLI


Expected results:
VM should exist until the VMI is also removed. foregroundDeletion should be added to the templates.


Additional info:

Comment 1 Fabian Deutsch 2020-09-07 09:14:22 UTC

foregroundDeletion is a nice idea on the VM in the template - from a user perspective we should just ensure that on the VM's phase goes into an "end game" state (Deletion, Termination, or so) in order to signal that the deleation is in progress.
The VM should not stay in the running phase while we do foreground deletion.

The reason is that they system should signal the user that his request got noticed and that it's processing this request (delete VM).

Omer, if we use foregroundDeletion on a VM, what phase will the VM be in once you delete it?

Comment 2 Fabian Deutsch 2020-09-14 14:48:57 UTC

In order to support this, we'd need KubeVirt to set ownerReference.blockOwnerDeletion=true.

Is this correct, Roman?

Comment 3 Roman Mohr 2020-09-14 15:00:56 UTC

(In reply to Fabian Deutsch from comment #2)
> In order to support this, we'd need KubeVirt to set
> ownerReference.blockOwnerDeletion=true.
> 
> Is this correct, Roman?

Yes. This is already the case. But this has only an effect if you choose the foreground delete strategy when you do the DELETE call.

Comment 4 Roman Mohr 2020-09-14 15:03:43 UTC

(In reply to Fabian Deutsch from comment #1)
> foregroundDeletion is a nice idea on the VM in the template - from a user
> perspective we should just ensure that on the VM's phase goes into an "end
> game" state (Deletion, Termination, or so) in order to signal that the
> deleation is in progress.
> The VM should not stay in the running phase while we do foreground deletion.
> 
> The reason is that they system should signal the user that his request got
> noticed and that it's processing this request (delete VM).
> 
> Omer, if we use foregroundDeletion on a VM, what phase will the VM be in
> once you delete it?

Note that the phase will not reflect that. The UI has to look at the deletion timestamp.
The deletion of a resource can very well be in progress, while the VM is definitely still running.

Comment 5 Fabian Deutsch 2020-09-14 15:04:58 UTC

    Ok, thanks.

    Then this is nothing we can do in the templates, but which can only be done by the caller, the UI in this case, and bug 1873402 is taking care of this already.
    Thus nothing we can do with this bug.

Comment 6 Roman Mohr 2020-09-14 15:42:03 UTC

Oh wait, manually putting the foregroundDeletion finalizer on the VM template may still work. I am just not sure if we are then in uncharted territory. Like the DELETE call could actually remove the finalizer since it is normally also the one which adds it.