Bug 1328071 - Template deletion should not fail even if its disk's deletion fails
Summary: Template deletion should not fail even if its disk's deletion fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 3.6.5.1
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.0.0-rc
: 4.0.0
Assignee: Maor
QA Contact: Carlos Mestre González
URL:
Whiteboard:
: 1179834 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-18 11:12 UTC by Carlos Mestre González
Modified: 2016-07-05 08:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: An attempt to delete a Template might fail and leave the Template in the setup if the deletion process of the first disk will fail to initiate. Consequence: The Template will be left in the setup, and any attempt to register an unregistered Template with the same name to the engine will fail. Fix: The behavior of removing the first disk should be the same as all the other disks. Once a disk will fail to be removed, the process should still continue and the disk should be removed from the setup with the Template. Result: Removing a Template should succeed
Clone Of:
Environment:
Last Closed: 2016-07-05 08:03:52 UTC
oVirt Team: Storage
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
tnisan: devel_ack+
acanan: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 57033 0 master MERGED core: Remove notYetRemoved condition from removeTemplateImages. 2016-05-23 13:07:05 UTC
oVirt gerrit 57948 0 master MERGED core: Delete template even if all disks failed to be deleted. 2016-05-24 12:54:18 UTC

Description Carlos Mestre González 2016-04-18 11:12:32 UTC
Description of problem:
I'm testing the import of a data domain. It's easier to explain with the flow


Version-Release number of selected component (if applicable):
rhevm-3.6.5.1-0.1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Have a data center with at least two domains, one block (iscsi in this case) and one file (nfs in this case)
2. Create a vm with boot disk on the block domain, and another disk on the file domain
3. create a template from that vm
4. Detach and deactivate the block domain. Remove it without formatting.
5. Import the domain and attach it and activate to the dc.
6. Try to register (import) the template from the block domain

Actual results:
6.1. Import fails since there's already an template with the same name in the system (expected I'm guessing since the file domain disk still exists and is attached to the object)

6.2. If before importing the template we REMOVE the current template, import succeeds, the template contains TWO DISKS (even though the file domain disk was removed before). If we try to remove the template now, the operation fails because it tried to remove the file domain disk:

VDSM command failed: Image does not exist in domain: u'image=93b9b34b-3dca-4d76-ad6e-991fc69d7b02, domain=7b03ee16-aaa1-402e-805d-e539e15a869f'

Then there's a template object in the system with the invalid image.


Expected results:
I have two expectations from this: 

6.1: Can the system via the template ID know the template was the same? in that case it should be possible to import it or ask the user if she/he wants to merge it.

6.2: When importing a template object with multiple disks, but some of then were not in the same domain, then the object should:
   6.2.1) No import the disk object that was not part of the domain
   6.2.2) Even if they're imported as an empty object then the template can be removed regardless?

6.1. seems like an RFE, but 6.2 seems both bugs (specially 6.2.2 since the object cannot be removed)

Comment 1 Sandro Bonazzola 2016-05-02 10:09:25 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 2 Maor 2016-05-04 12:12:48 UTC
(In reply to Carlos Mestre González from comment #0)
> Description of problem:
> I'm testing the import of a data domain. It's easier to explain with the flow
> 
> 
> Version-Release number of selected component (if applicable):
> rhevm-3.6.5.1-0.1.el6.noarch
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. Have a data center with at least two domains, one block (iscsi in this
> case) and one file (nfs in this case)
> 2. Create a vm with boot disk on the block domain, and another disk on the
> file domain
> 3. create a template from that vm
> 4. Detach and deactivate the block domain. Remove it without formatting.
> 5. Import the domain and attach it and activate to the dc.
> 6. Try to register (import) the template from the block domain
> 
> Actual results:
> 6.1. Import fails since there's already an template with the same name in
> the system (expected I'm guessing since the file domain disk still exists
> and is attached to the object)
> 
> 6.2. If before importing the template we REMOVE the current template, import
> succeeds, the template contains TWO DISKS (even though the file domain disk
> was removed before). If we try to remove the template now, the operation
> fails because it tried to remove the file domain disk:


Probably since the disk didn't finished to get deleted while the register of the Template started, the template register was succeeded.

> 
> VDSM command failed: Image does not exist in domain:
> u'image=93b9b34b-3dca-4d76-ad6e-991fc69d7b02,
> domain=7b03ee16-aaa1-402e-805d-e539e15a869f'
> 
> Then there's a template object in the system with the invalid image.
> 
> 
> Expected results:
> I have two expectations from this: 
> 
> 6.1: Can the system via the template ID know the template was the same? in
> that case it should be possible to import it or ask the user if she/he wants
> to merge it.


There is already an open RFE at the https://bugzilla.redhat.com/1108904
Currently engine doesn't supports semi imports of entities.

> 
> 6.2: When importing a template object with multiple disks, but some of then
> were not in the same domain, then the object should:
>    6.2.1) No import the disk object that was not part of the domain
>    6.2.2) Even if they're imported as an empty object then the template can
> be removed regardless?

Indeed, the Template remove should succeed and perhaps only the Template's disk should be set to ILLEGAL.

> 
> 6.1. seems like an RFE, but 6.2 seems both bugs (specially 6.2.2 since the
> object cannot be removed)

Comment 3 Maor 2016-05-04 12:36:47 UTC
rephrased the summary to indicate the bug more clearly, feed free to fix it as you please.
Failed deleted disks should be marked as ILLEGAL

Comment 4 Allon Mureinik 2016-05-24 09:13:30 UTC
Maor, can we have a doctext explain the behavior here? Thanks!

Comment 5 Maor 2016-05-24 11:10:22 UTC
Cause: 
An attempt to delete a Template might fail and leave the Template in the setup if the deletion process of the first disk will fail to initiate.

Consequence: 
The Template will be left in the setup, and any attempt to register an unregistered Template with the same name to the engine will fail.

Fix: 
The behavior of removing the first disk should be the same as all the other disks.
Once a  disk will fail to be removed, the process should still continue and the disk should be removed from the setup with the Template.

Result: 
Removing a Template should succeed

Comment 6 Maor 2016-06-08 13:35:23 UTC
*** Bug 1179834 has been marked as a duplicate of this bug. ***

Comment 7 Carlos Mestre González 2016-06-15 23:01:14 UTC
Template was removed without any issue

version: rhevm-4.0.0.4-0.1.el7ev.noarch

Comment 8 Sandro Bonazzola 2016-07-05 08:03:52 UTC
oVirt 4.0.0 has been released, closing current release.


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