Bug 1226562

Summary: Command-coordination: persist engine lock that is passed to command
Product: [oVirt] ovirt-engine Reporter: Arik <ahadas>
Component: GeneralAssignee: Ravi Nori <rnori>
Status: CLOSED NOTABUG QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: unspecified    
Version: ---CC: bugs, gklein, lpeer, lsurette, mperina, oourfali, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone: ovirt-4.0.0-alphaFlags: ylavi: ovirt-4.0.0?
rule-engine: planning_ack?
mperina: devel_ack+
rule-engine: testing_ack?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-25 15:39:07 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:
Bug Depends On: 1302293    
Bug Blocks: 952703, 1236075    

Description Arik 2015-05-30 17:10:03 UTC 
Description of problem:
When running a command using the command coordination framework that is given an engine lock from the caller command, the lock is not persisted. The problem is that if the lock should be used for the entire execution of the command, the lock will not be released after the execute phase and we will not be able to release if afterwards because it cannot be restored.

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


How reproducible:
100%

Steps to Reproduce:
1. Run an internal command as async-execution using the command coordination. The command should receive an engine lock from the caller command and store it for its entire execution.

Actual results:
The lock will not be released when calling the endAction method of the command from its callback.

Expected results:
The lock should be released when calling the endAction method of the command from its callback.

Additional info:
This problem is not unique to the command-coordination framework but now that we persist the command entity, we should also persist locks that are passed to the command, otherwise we will not be able to reproduce them (unless we create the parent command for that, which is a not a good solution imho)
Comment 1 Red Hat Bugzilla Rules Engine 2015-11-30 19:11:19 UTC 
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 2 Ravi Nori 2016-04-25 15:39:07 UTC 
To pass the lock from parent command to the child command the CommandContext passed to executeAsyncCommand should contain the lock. cloneContextAndDetachFromParent() removes the lock, so the right way to invoke the async execution would be to clone the command context with out compensation and execution context but keeping the locks intact.

example code snippet

    CommandCoordinatorUtil.executeAsyncCommand(
           VdcActionType.ConvertVm,
           buildConvertVmParameters(),
           cloneContext().withoutCompensationContext().withoutExecutionContext();
    }