Bug 1250167 - Possible race when using events for vm status
Summary: Possible race when using events for vm status
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Arik
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-04 15:53 UTC by Omer Frenkel
Modified: 2022-05-16 07:48 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-08-14 11:32:45 UTC
oVirt Team: Virt
Embargoed:
sbonazzo: ovirt-4.2-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-46052 0 None None None 2022-05-16 07:48:09 UTC

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.


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