Bug 1328071
| Summary: | Template deletion should not fail even if its disk's deletion fails | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Carlos Mestre González <cmestreg> |
| Component: | BLL.Storage | Assignee: | Maor <mlipchuk> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Carlos Mestre González <cmestreg> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6.5.1 | CC: | amureini, bugs, mlipchuk, tnisan, tspeetje |
| Target Milestone: | ovirt-4.0.0-rc | Flags: | rule-engine:
ovirt-4.0.0+
rule-engine: planning_ack+ tnisan: devel_ack+ acanan: testing_ack+ |
| Target Release: | 4.0.0 | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-05 08:03:52 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
Carlos Mestre González
2016-04-18 11:12:32 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA. (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) 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 Maor, can we have a doctext explain the behavior here? Thanks! 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 *** Bug 1179834 has been marked as a duplicate of this bug. *** Template was removed without any issue version: rhevm-4.0.0.4-0.1.el7ev.noarch oVirt 4.0.0 has been released, closing current release. |