Bug 873697

Summary: If compensation related data has associated tasks, it should not be cleaned at engine start, but should be after endSuccessfully or endWithFailure occurs
Product: Red Hat Enterprise Virtualization Manager Reporter: Yair Zaslavsky <yzaslavs>
Component: ovirt-engineAssignee: Yair Zaslavsky <yzaslavs>
Status: CLOSED WONTFIX QA Contact: Haim <hateya>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: bazulay, dyasny, iheim, lpeer, oourfali, Rhev-m-bugs, sgrinber, yeylon, ykaul
Target Milestone: ---   
Target Release: 3.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-20 08:12:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.