Bug 1250167 - Possible race when using events for vm status
Possible race when using events for vm status
Status: CLOSED WONTFIX
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
---
Unspecified Unspecified
medium Severity medium (vote)
: ovirt-4.2.0
: ---
Assigned To: Arik
Pavel Stehlik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 11:53 EDT by Omer Frenkel
Modified: 2017-08-14 07:32 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-14 07:32:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Omer Frenkel 2015-08-04 11:53:35 EDT
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 11:57:38 EDT
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 03:33:06 EDT
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 07:03:34 EDT
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 06:10:06 EDT
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 (Dary) 2016-05-23 09:25:59 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 7 Yaniv Lavi (Dary) 2016-05-23 09:26:27 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 8 Tomas Jelinek 2016-05-31 09:59:24 EDT
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 04:09:38 EST
The bug was not addressed in time for 4.1. Postponing to 4.2
Comment 10 Tomas Jelinek 2017-08-14 07:32:45 EDT
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.