Bug 1226561 - Command-coordination: re-acquire engine lock after engine restart
Summary: Command-coordination: re-acquire engine lock after engine restart
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.0.2
: 4.0.2
Assignee: Ravi Nori
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks: 952703 1236075 1339536
TreeView+ depends on / blocked
 
Reported: 2015-05-30 16:57 UTC by Arik
Modified: 2016-08-22 12:30 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1339536 (view as bug list)
Environment:
Last Closed: 2016-08-22 12:30:59 UTC
oVirt Team: Infra
Embargoed:
rule-engine: ovirt-4.0.z+
rule-engine: planning_ack+
mperina: devel_ack+
lsvaty: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 56643 0 master MERGED engine : Command-coordination: re-acquire engine lock after engine restart 2016-07-12 13:51:29 UTC
oVirt gerrit 60761 0 ovirt-engine-4.0 MERGED engine : Command-coordination: re-acquire engine lock after engine restart 2016-07-17 08:19:38 UTC

Description Arik 2015-05-30 16:57:04 UTC
Description of problem:
The command coordination framework persists commands and if the engine restarts in while the command's callback is polling, the polling will continue when the engine starts. The problem is that the engine lock is not being acquired again.

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


How reproducible:
100%

Steps to Reproduce:
1. Run a command that takes engine locks for the entire execution as async command using the command coordination framework.
2. When the execution is finished and the callback starts polling, restart the engine.

Actual results:
After the engine starts, the polling will continue but the engine lock is not acquired again.

Expected results:
The engine lock should be acquired again.
It would be great to have some kind of hook so additional operation could be done when the callback starts polling after engine restart.

Additional info:

Comment 1 Red Hat Bugzilla Rules Engine 2015-11-30 19:10:56 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 Sandro Bonazzola 2016-05-02 09:52:31 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:15:38 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 4 Yaniv Lavi 2016-05-23 13:20:57 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 5 Martin Perina 2016-07-12 13:52:35 UTC
Moving back to POST as we need to backport patch to ovirt-engine-4.0 branch

Comment 6 Lukas Svaty 2016-08-19 12:14:33 UTC
verified in ovirt-engine-4.0.2.6-0.1.el7ev.noarch

verification steps:
1. acquire lock -> create VM snapshot
2016-08-19 12:08:04,551 INFO  [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] (default task-32) [25610e94] Lock Acquired to object 'EngineLock:{exclusiveLocks='[e6f01eca-9eae-45fc-98d6-a46355be8a71=<VM, ACTION_TYPE_FAILED_SNAPSHOT_IS_BEING_TAKEN_FOR_VM$VmName appliance3>]', sharedLocks='null'}'

2. restart ovirt-engine
3. check lock was acquired again after restart
2016-08-19 12:09:17,024 INFO  [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] (ServerService Thread Pool -- 44) [] Lock Acquired to object 'EngineLock:{exclusiveLocks='[e6f01eca-9eae-45fc-98d6-a46355be8a71=<VM, ACTION_TYPE_FAILED_SNAPSHOT_IS_BEING_TAKEN_FOR_VM$VmName appliance3>]', sharedLocks='null'}'

3. check lock was freed correctly
2016-08-19 12:11:13,764 INFO  [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] (DefaultQuartzScheduler5) [] Lock freed to object 'EngineLock:{exclusiveLocks='[e6f01eca-9eae-45fc-98d6-a46355be8a71=<VM, ACTION_TYPE_FAILED_SNAPSHOT_IS_BEING_TAKEN_FOR_VM$VmName appliance3>]', sharedLocks='null'}'


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