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)
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.
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(); }