Bug 1226561

Summary:	Command-coordination: re-acquire engine lock after engine restart
Product:	[oVirt] ovirt-engine	Reporter:	Arik <ahadas>
Component:	General	Assignee:	Ravi Nori <rnori>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Lukas Svaty <lsvaty>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bugs, gklein, lpeer, lsurette, lsvaty, mperina, oourfali, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone:	ovirt-4.0.2	Flags:	rule-engine: ovirt-4.0.z+ rule-engine: planning_ack+ mperina: devel_ack+ lsvaty: testing_ack+
Target Release:	4.0.2
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1339536 (view as bug list)		Environment:
Last Closed:	2016-08-22 12:30:59 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:
Bug Blocks:	952703, 1236075, 1339536

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'}'