Bug 1820192 - Datavolumes are not removed on vm disk removal
Summary: Datavolumes are not removed on vm disk removal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.5.0
Assignee: Filip Krepinsky
QA Contact: Radim Hrazdil
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-02 13:38 UTC by Filip Krepinsky
Modified: 2020-07-13 17:25 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Datavolumes were not deleted on Disk removal Consequence: Datavolumes/PVC were kept alive until the VM was deleted. VM deletion did not offer any choice of keeping these DVs Fix: You can choose if you wish to delete/preserve DVs on Disk and also on VM deletion Result: DVs and PVC can be preserved outside of VM's lifecycle. This does not apply for Disks deleted through CD-ROM modal.
Clone Of:
Environment:
Last Closed: 2020-07-13 17:25:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift console pull 5457 None closed Bug 1820192: ask before deleting referenced VM resources 2020-07-28 08:57:02 UTC
Red Hat Product Errata RHBA-2020:2409 None None None 2020-07-13 17:25:22 UTC

Description Filip Krepinsky 2020-04-02 13:38:42 UTC
Description of problem:

Underlying datavolume or PVC is not removed on VM disk removal. So the data (DV and PVC) stays there


How reproducible:
100


Expected results:
The DV or PVC should be removed if the owner of that object is the VM.

Comment 1 Tomas Jelinek 2020-04-06 12:38:20 UTC
Probably we should have an option on the UI to decide if we want to delete also the disks or only the VM. Currently to not to touch the disks is the safer option so lets leave it like this in 4.4 and re-evaluate in 4.5.

FYI: Nelly

Comment 2 Guohua Ouyang 2020-04-23 00:38:05 UTC
Please note remove CDROM also cannot remove the DV, need to fix for CDROM as well.

Comment 3 Nelly Credi 2020-04-23 12:01:31 UTC
ack

Comment 4 Filip Krepinsky 2020-05-05 12:11:16 UTC
we should also ask if the user wants to remove associated VirtualMachineImport resource

Comment 5 Filip Krepinsky 2020-05-05 12:48:51 UTC
We should also patch DV owner references accordingly.

Comment 6 Filip Krepinsky 2020-05-05 12:52:33 UTC
Should we show a table of disks so the user can select which to preserve and which to keep? 

This would be very useful especially for attached disks which were not cloned before and there is no ownership set (I would imagine these to be deselected by default).
Or should we not care about disks which the VM doesn't own at all - but still uses - this includes also secrets. etc.

Comment 7 Tomas Jelinek 2020-05-05 13:36:21 UTC
(In reply to Filip Krepinsky from comment #6)
> Should we show a table of disks so the user can select which to preserve and
> which to keep? 

certainly not as a bugfix. As a 4.5 bugfix we might add a checkbox but not a whole table.
But we might consider it for 4.6

> 
> This would be very useful especially for attached disks which were not
> cloned before and there is no ownership set (I would imagine these to be
> deselected by default).
> Or should we not care about disks which the VM doesn't own at all - but
> still uses - this includes also secrets. etc.

I don't think we should touch them at all. Those things are more often than not reused in the env so deleting one VM using them should not affect them

Comment 8 Yaacov Zamir 2020-05-17 06:07:31 UTC
> As a 4.5 bugfix we might add a checkbox but not a whole table.
But we might consider it for 4.6

Moving to 4.6

Notes:
a - the scope of this bug is bigger then a bug fix
b - in normal cases data-volumes, persistent-volumes, secrets and config maps should persist after vm is deleted.
c - since the deletion of data-volumes is a dangerous operation (may cause data lost) we need some design work on this

@Matt will you have the capacity to do a design for this for 4.6 ?

Comment 9 Yaacov Zamir 2020-05-17 06:46:46 UTC
@Tomas hi, I un-targeted 4.5 because it looks big (not a bug) WDYT ?

Comment 10 Yaacov Zamir 2020-05-18 07:35:18 UTC
@Matt hi,

off line we decided to re-targer it to 4.5 , but we want you opinion on the design changes, do you think it will make UX better ?

Comment 11 Filip Krepinsky 2020-05-18 10:06:22 UTC
> b - in normal cases data-volumes, persistent-volumes, secrets and config maps should persist after vm is deleted.

The most usual case is that the VM will own the DV, unless you click Attach Disk (not Attach Cloned PVC). 

These DVs and PVCs are deleted on VM deletion (Currently without asking).

Comment 15 Radim Hrazdil 2020-05-27 09:44:14 UTC
Verified that disks owned by a VM are deleted when the VM is deleted.
That is - blank disks, attached cloned disks, URL disks.
Attached disks (not cloned) are not removed.

release-4.5, commit: 91e682e014286e243085dcb168480d54b913a010

Comment 16 Filip Krepinsky 2020-05-27 10:41:26 UTC
Btw, standalone disk removal should be tested too:

there are two states depending on the "delete DV/PVC" checkbox:
- Disk is removed immediately while VM object is still present
- Disk is not removed and lives even after VM deletion.

The VM removal itself have these options for all disks.

Comment 18 errata-xmlrpc 2020-07-13 17:25:01 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/RHBA-2020:2409


Note You need to log in before you can comment on or make changes to this bug.