Feature #1524

Driver operation journaling

Added by Carlos Martín over 8 years ago. Updated over 8 years ago.

Status:ClosedStart date:10/03/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Core & System
Target version:-
Resolution:duplicate Pull request:

Description

High level design:

  • Add a unique ID to each driver operation (e.g. DEPLOY <vm_id>).
  • The core will keep track of the pending operations, in memory and the DB.
  • When a new operation is started, all the pending ones are cancelled, or tagged to be ignored when (and if) they return.
  • At boot time, oned will check the pending operations, and try to recover: either retry them, or assume a failed operation result.

The rationale behind:

Let's say a VM is being deployed to Host A. It is in BOOT, waiting for a DEPLOY SUCCESS/FAILURE.
The user gets tired of waiting, executes a onevm resubmit, and the scheduler deploys the VM to Host B.

Now the first deploy action to A ends, and returns a DEPLOY SUCCESS, so oned gets confused and thinks the VM got successfully deployed to the Host B.

This can happen with different states and operations, causing incorrect state transitions and inconsistent Host capacity (cpu and memory) counters.


Related issues

Duplicates Backlog #1614: Add an action queue to driver managers Closed 10/26/2012

History

#1 Updated by Daniel Molina over 8 years ago

It would be a nifty feature to be able to list the actions pending on a host. Therefore an admin can check if a tm clone is taking too much time...

#2 Updated by Carlos Martín over 8 years ago

  • Status changed from New to Closed
  • Resolution set to duplicate

Due to a amaizingly short memory span I duplicated this one...

#3 Updated by Ruben S. Montero over 8 years ago

  • Target version deleted (Release 4.0)

Also available in: Atom PDF