Bug 1250167

Summary:	Possible race when using events for vm status
Product:	[oVirt] ovirt-engine	Reporter:	Omer Frenkel <ofrenkel>
Component:	General	Assignee:	Arik <ahadas>
Status:	CLOSED WONTFIX	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	---	CC:	bugs, lsurette, michal.skrivanek, rbalakri, srevivo, tjelinek, ykaul
Target Milestone:	---	Flags:	sbonazzo: ovirt-4.2-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-14 11:32:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Omer Frenkel 2015-08-04 15:53:35 UTC

Description of problem:
engine might get event on a status, which is not relevant anymore, because the status was already changed by the engine.

scenario for example:
vm is powering-up, user select to migrate the vm, the moment the engine change the status to 'migrating-from' event received with 'up' on the source host.
this will cause the engine to think the migration failed.


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

How reproducible:
hard to reproduce

Comment 1 Omer Frenkel 2015-08-04 15:57:38 UTC

the problem is the engine cannot differ between the 'up' event received by chance because the vm moved from powering-up to up the moment the migration requested or because migration failed.

we discussed the following possible solution:

use VDSM's time ("motify time") when engine changes VM
- when the engine triggers an operation in VDSM that is expected to change VM's status, it gets back the time in VDSM and we will use it as a timestamp
Pros:
- less changes in the backend
- one clock
Cons:
- changes the API between VDSM and engine

Comment 2 Omer Frenkel 2015-09-08 07:33:06 UTC

since this is currently only theoretical race, and wasn't reported by anyone using the system, pushing to 4.0

Comment 3 Red Hat Bugzilla Rules Engine 2015-10-19 11:03:34 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 5 Sandro Bonazzola 2016-05-02 10:10:06 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 6 Yaniv Lavi 2016-05-23 13:25:59 UTC

oVirt 4.0 beta has been released, moving to RC milestone.

Comment 7 Yaniv Lavi 2016-05-23 13:26:27 UTC

oVirt 4.0 beta has been released, moving to RC milestone.

Comment 8 Tomas Jelinek 2016-05-31 13:59:24 UTC

since this is still a theoretical race no one have ever faced in reality, pushing to 4.1

Comment 9 Michal Skrivanek 2016-12-21 09:09:38 UTC

The bug was not addressed in time for 4.1. Postponing to 4.2

Comment 10 Tomas Jelinek 2017-08-14 11:32:45 UTC

This bug has been opened in 2015 as a theoretical possibility. It was never actually hit by anyone in this 2 years. Also the consequence is only a failed migration which will pass on next try.

Closing due to capacity. Please feel free to reopen if you think this is an important thing.