Bug 1306732 - [TRACKER] Live Merge recovery after merge has gaps
Summary: [TRACKER] Live Merge recovery after merge has gaps
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.0.0-rc
: 4.0.0
Assignee: Ala Hino
QA Contact: Kevin Alon Goldblatt
URL:
Whiteboard:
Depends On: 1227497 1302215 1306741 1308501
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-11 16:44 UTC by Greg Padgett
Modified: 2016-08-01 12:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-01 12:25:22 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
rule-engine: devel_ack+
acanan: testing_ack+


Attachments (Terms of Use)

Description Greg Padgett 2016-02-11 16:44:07 UTC
The failure/recovery flow for Live Merge has gaps in its effectiveness to successfully detect failures and write the database records in such a way as to make Live Merge succeed upon retry without manual fixup.

For one example, see bug 1227497 and bug 1302215 - the fix here helps avoid failure from vdsm not being able to report the status of DestroyImageCommand, but may still fail if the SPM is unavailable during the verification.

This bug is for investigating a more thorough, long-term fix wherein the Live Merge failure flow is made more predicable and (we hope) simplified.

Comment 1 Allon Mureinik 2016-02-28 14:40:53 UTC
This is a dedicated research task that should be examined together with the refactoring efforts of 4.0.

When specific items are discovered (e.g., the aforementioned bug 1227497 and bug 1302215), their targeting should be discussed individually.

Comment 2 Sandro Bonazzola 2016-05-02 09:48:17 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 3 Yaniv Lavi 2016-05-23 13:13:11 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 4 Yaniv Lavi 2016-05-30 11:48:55 UTC
Do you think there is still any action items on this?

Comment 5 Ala Hino 2016-05-30 11:59:52 UTC
Not for the short term

Comment 6 Allon Mureinik 2016-05-30 14:27:07 UTC
Moving to ON_QA based on this assessment.

Comment 7 Allon Mureinik 2016-06-09 13:15:42 UTC
Ala, I'm pretty any doctext requirements are handled by the dependent bugs, just wanted to verify this though - please keep me honest here.

Comment 9 Ala Hino 2016-06-14 11:04:57 UTC
Actually, doctext  requirements are handled in BZ 1323629, which is dedicated for LM recovery documentation

Comment 10 Aharon Canan 2016-07-05 08:27:45 UTC
anything to test here? is it tracker only?

Comment 11 Ala Hino 2016-07-18 14:49:47 UTC
A tracker

Comment 12 Allon Mureinik 2016-07-18 16:17:37 UTC
(In reply to Ala Hino from comment #11)
> A tracker
Can you add all the BZs it's supposed to track? I see just two bugs (BZ#1227497 and BZ#1302215, which were handled in 3.6.3), but I know you did a bunch of work in 3.6.5 and 3.6.6.

Comment 13 Kevin Alon Goldblatt 2016-07-19 11:30:12 UTC
Verified that there is no action item on this bz. This is only a tracker


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