Bug 873697 - If compensation related data has associated tasks, it should not be cleaned at engine start, but should be after endSuccessfully or endWithFailure occurs
Summary: If compensation related data has associated tasks, it should not be cleaned a...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.2.0
Assignee: Yair Zaslavsky
QA Contact: Haim
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-06 14:07 UTC by Yair Zaslavsky
Modified: 2016-02-10 19:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-20 08:12:27 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Yair Zaslavsky 2012-11-06 14:07:22 UTC
Description of problem:

Example of scenario -

During preview of snapshots , the code creates a new active snapshot.
Compensation table will contain indication a new entity was added.
If engine crashes, compensation logic removes the added entity, and at the endSuccessfuly method, there is usage of the added snapshot- but it does not exist - NPE occurs.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Yair Zaslavsky 2012-11-08 14:54:35 UTC
Suggested patch upstream 

http://gerrit.ovirt.org/#/c/9122/

Comment 5 Barak 2013-01-09 13:24:24 UTC
After discussing the issue in depth with Liron, it looks like we are better off without this fix. 

Today the command mechanism relies on the compensation to be reverted on engine restart as a way to understand that not all subcommands were actually executed,  hence each parent command need to validate all the new entities it had created still exist in the DB (and not reverted ...) on endSuccessfully. So today we are better off without this fix, as it will often falsely assume that the parent command succeeded (not reverted) even if some of it's sub commands did not even start.


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