Hide Forgot
Description of problem: Modifying "wipe after delete" flag is available via rest-api while oVirt docs state this flag should be not available for file domain(UI greys this option as expected). engine=# SELECT vm_names,storage_type,disk_id,storage_name,wipe_after_delete from images_storage_domain_view ; vm_names | storage_type | disk_id | storage_name | wipe_after_delete ----------+--------------+--------------------------------------+--------------+------------------- vm_test | 3 | e1a05b5b-5781-4bda-9cdf-c165359aa8a1 | ISCSI | f vm_test | 1 | 64feaf6f-1333-4517-9f75-a0038bb55cee | nfs | t vm_test | 3 | 8a422c1e-7cb4-4dba-b94e-44272c89bf40 | ISCSI | f Version-Release number of selected component (if applicable): beta.1 && av10.3 How reproducible: 100% Steps to Reproduce: SomeNfsDisk.set_wipe_after_delete(True) SomeNfsDisk.update() Actual results: operation successful Expected results: operation should be disabled Additional info:
The RESTAPI doesn't contain logic to check the type of the the storage domain, it just passes the data given by the caller to the backend. If this should be ignored or cause an error then it should be done in the backend.
(In reply to Ori from comment #0) > Description of problem: > Modifying "wipe after delete" flag is available via rest-api while oVirt > docs state this flag should be not available for file domain(UI greys this > option as expected). Actually, I'm not quite sure this is the way we'd like to do. Since 3.4 we allow moving disks from block storage to file storage, so perhaps we'd like to keep this parameter as a "logical" parameter and only act upon in case the underlying storage makes sense (see bug 1097820). However, I agree the two interfaces should be aligned - either both GUI and REST should allow it, or they should both block it. Sean - your two cents?
(In reply to Allon Mureinik from comment #2) > (In reply to Ori from comment #0) > > Description of problem: > > Modifying "wipe after delete" flag is available via rest-api while oVirt > > docs state this flag should be not available for file domain(UI greys this > > option as expected). > > Actually, I'm not quite sure this is the way we'd like to do. Since 3.4 we > allow moving disks from block storage to file storage, so perhaps we'd like > to keep this parameter as a "logical" parameter and only act upon in case > the underlying storage makes sense (see bug 1097820). > IMHO if the disk is moved from a block domain the flag should be set by the user > However, I agree the two interfaces should be aligned - either both GUI and > REST should allow it, or they should both block it. > > Sean - your two cents? Indeed the two interfaces should be aligned, to keep it simple they should both block it. Sean
Sean, after giving the issue some more thought, I think the better approach would be to just allow setting it in the UI and change the field name to "treat securely" or something less asinine to the same effect. What happens when you move a disk with WAD=true from a block domain to a file domain? - Blocking the operation would consist of bad UX - Clearing the WAD flag would be inconsistent with other move operations, which do not modify other properties. Additionally, consider the flow of moving a disk block1>file->block. You'd end up with a disk with different properties although you theoretically moved it back to where it came from. - Simply allowing it will have all the problems of the current situation, with the additional inconsistency of why can I get a WAD disk on a file domain by moving it but not straight-forward by creating it. My suggestion: - Allow it in the GUI - Change the property to address the functionality and not the implementation (e.g., "secure deleting") - Add a warning when moving from a file domain to a block domain. Sean - ack/nack
(In reply to Allon Mureinik from comment #4) > Sean, after giving the issue some more thought, I think the better approach > would be to just allow setting it in the UI and change the field name to > "treat securely" or something less asinine to the same effect. > > What happens when you move a disk with WAD=true from a block domain to a > file domain? > - Blocking the operation would consist of bad UX > - Clearing the WAD flag would be inconsistent with other move operations, > which do not modify other properties. Additionally, consider the flow of > moving a disk block1>file->block. You'd end up with a disk with different > properties although you theoretically moved it back to where it came from. Indeed, this raises another security consistency consideration... > - Simply allowing it will have all the problems of the current situation, > with the additional inconsistency of why can I get a WAD disk on a file > domain by moving it but not straight-forward by creating it. > > My suggestion: > - Allow it in the GUI > - Change the property to address the functionality and not the > implementation (e.g., "secure deleting") > - Add a warning when moving from a file domain to a block domain. +1 on the warning, Ack on "secure deleting" property change. Sean
I added a clone of this bug for the warning part - bug 1127781. This bug will deal with enabling "wipe after delete" for file domains.
reproduced on rhevm vt3.1
Ori, this worked fine on our dev envs - please add exact steps to reproduce and the output of "rpm -qa | grep ovirt". Thanks!
To summarize the expected result: 1. Via GUI/REST you can always specify Wipe After Delete. 2. On File Domains, this property is not acted upon (as per bug 1097820). 3. Looking forward - we should have a warning when MOVING a disk WITHOUT Wipe After Delete for a file domain (as per bug 1127781). The verification of THIS bug should only check (1).
agreed,hence,the steps to verify this bug are now changed and will be as follows: 1. check via UI,rest-api that "wipe_after_delete" check flag is enabled and not greyed out on every creation pop up window. 2. deleting those disks (on File) sends PostZero=False to vdsm
verified on vt3.1
oVirt 3.5 has been released and should include the fix for this issue.
*** Bug 1223697 has been marked as a duplicate of this bug. ***