Bug 1122571

Summary: Webadmin's Block disk status is not correlated with vdsm operation,in case disk's "wipe after delete" flag is True
Product: [Retired] oVirt Reporter: Ori Gofen <ogofen>
Component: ovirt-engine-webadminAssignee: Allon Mureinik <amureini>
Status: CLOSED DEFERRED QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5CC: acanan, acathrow, amureini, ecohen, gklein, iheim, lsurette, mgoldboi, yeylon
Target Milestone: ---   
Target Release: 3.4.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-23 17:01:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ori Gofen 2014-07-23 14:16:25 UTC
Description of problem:
when creating a large block disk (the larger the disk,the larger the problem)
and marking "wipe after delete" flag as 'True',then removing this disk.
disk existence is wiped from the UI while actually,removing this kind of disk takes a lot of time(since vdsm has to fill the whole disk with zero's).
this can be very misleading to an unaware sysadmin.

for example:
Deleting two 30G disks(wipe_after_delete='True') on iscsi took almost 25 minutes
async task table reported this two assignment as being executed

engine=# SELECT step_id,action_type,task_params_class from async_tasks;
               step_id                | action_type |                     task_params_class                     
--------------------------------------+-------------+-----------------------------------------------------------
 e7c89068-df9d-4ff4-ac63-8d6e6d9bed98 |         230 | org.ovirt.engine.core.common.action.RemoveImageParameters
 c961cc72-ae3d-4d03-9463-6750e28f8228 |         230 | org.ovirt.engine.core.common.action.RemoveImageParameters
(2 rows)

lv's were activated and writable

6c65483f-5316-474a-b04b-4cb397a8a870 db7d2a45-45e7-457c-b40f-47670dda811d -wi-ao----  30.00g                                             
  7c163ea3-fe24-435f-a9e1-dcfe9093d2c0 db7d2a45-45e7-457c-b40f-47670dda811d -wi-ao----  30.00g 

and during all this time (25 minuts),UI reported on an unused ISCSI domain(with no disks or vm's on it) with 1G free space(out of 65G)

Version-Release number of selected component (if applicable):
beta.1 && av10.3

How reproducible:
100%

Steps to Reproduce:
1.delete a block disk with "wipe after delete" flag 'True'

Actual results:
UI is not correlated with the procedure

Expected results:
the disks should be marked as "locked" as long as the operation of using(deleting) them is present at the async_tasks sql table.

Additional info:

Comment 1 Allon Mureinik 2014-07-23 17:01:01 UTC
Once we've started deleting a disk oVirt considers it removed - it can never be restored, and is no longer part of the system.

We might want to add some introspection capabilities to the garbage collector once its implemented (post SPM-removal), but we aren't going to do anything about this now.