(Difference between revisions)
Jump to: navigation, search

Features/Serial Execution of Asynchronous Tasks Detailed Design

(User work-flows: workflow diagram)
(User work-flows: added DFD)
 
Line 62: Line 62:
 
==== User work-flows ====
 
==== User work-flows ====
  
 +
Flow chart:
 
[[File:SEAT_flow.png]]
 
[[File:SEAT_flow.png]]
 +
 +
DFD:
 +
[[File:SEAT_DFD.png]]
  
 
===== Successful Execution =====
 
===== Successful Execution =====

Latest revision as of 08:26, 29 August 2012

Contents

[edit] Serial Execution of Asynchronous Tasks Detailed Design

[edit] Summary

Currently, oVirt Engine has an abilitty to run an asynchronous task on the SPM. When the task completes, AsyncTaskManager re-creates the command and calls its EndAction(), which is pivoted to EndSuccessfully() or EndWithFailure(), depending on the result of the SPM task. This feature aims to extend this behaviour to allow an engine command to fire a series of aysnchronous SPM tasks in order to allow complex flows (e.g., Live Storage Migration, proper error handling in Move Disk) to be implemented.

See also the main feature page.

[edit] Owner


[edit] Current status

  • Target Release: 3.1
  • Status: Design Review
  • Last updated date: 09/08/2012


[edit] Detailed Description

This feature will break the coupling where an engine command equals an SPM task. It will allow the engine to manage complicated asynchronous flows, possibly across several hosts.


[edit] Entity Description

SEAT classes.png

[edit] SPMAsyncTask

A new property, executionIndex (int) will be added, to signify the position of this task in a command's flow.

[edit] SPMAsyncTaskHandler

This new entity will represent how oVirt engine handles a single SPMAsyncTask, instead of how it's handled by CommandBase today. Its methods:

  • beforeTask - the execution carried out on the engine side before firing an async task. This is analogous the today's executeAction() body, and includes updating BEs and persisting them in the databsae.
  • createTask - how to create the async task
  • endSuccessfully - the code to run when a task ends successfully
  • endWithFailure - the code to run when a task ends unsuccessfully
  • compensate - the code to run if a completed task needs to be undone - see below.
[edit] CommandBase

CommandBase will hold a List of SPMAsyncTaskHandler to manage executing of SPMAsyncTasks Basically, execute() will iterate over the handlers and execute each. See details below.

[edit] EntireCommandSPMAsyncTaskHandler

This is a dummy class to mimic the old behavior of command base under the new design. It holds a reference to the wrapping CommandBase object and implemented SPMAsyncTaskHandler as follows:

  • beforeTask - calls CommandBase.executeAction()
  • createTask - returns null - is handled in the beforeTask()
  • endSuccessfully - calls CommandBase.endSuccessfully()
  • endWithFailure - calls CommandBase.endWithFailure()
  • compensate - empty, implemented in endWithFailure()

[edit] CRUD

SPMAsyncTask's CRUD operations should consider the new property. Other objects do not have interesting CRUD operations.

[edit] User Experience

N / A

[edit] Installation/Upgrade

N / A

[edit] User work-flows

Flow chart: SEAT flow.png

DFD: SEAT DFD.png

[edit] Successful Execution

instead of calling executeCommand() CommandBase will iterate over its SPMAsyncTaskHandlers and execute them. The defalut EntireCommandSPMAsyncTaskHandler will simply call the command's executeAction for backwards compatibility. For each one, CommandBase calls beforeTask(), and then fires an SPM command according to createTask(). When the command ends, AsyncTaskManager wakes up the handler, and it runs endSuccessfully(). CommandBase then starts the process over again with the next handler.

Note: the treatment of HSM commands remains synchronious, as has no bearing on this proposed feature's design.

[edit] Unsuccessful Execution

See the execution flow above. When an SPM task fails, the relevant handler is awoken, and it calls endWithFailure(). CommandBase then iterates in a reverse order, and calls each handler's compensate.

[edit] Events

[edit] JBoss Restart/Crash

When JBoss starts, task polling is restarted (as before this change). The only change is that now tasks are now persisted with their executionIndex, so when a tasks completes the command issuing it can be resumed from the correct place.

[edit] Dependencies / Related Features and Projects

Live Storage Migration depends on this feature. This feature will also allow for better error handling in various Move Disk scenarios.

[edit] Documentation / External references

N / A at the moment

[edit] Comments and Discussion

Talk:Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design

[edit] Open Issues

N / A