<commit_before>---
title: TaskManagerDetailed
category: feature
authors: lpeer, moti, sandrobonazzola
wiki_category: Feature|TaskManager
wiki_title: Features/TaskManagerDetailed
wiki_revision_count: 101
wiki_last_updated: 2015-01-16
---

## Task Manager

### Summary

A Task Manager is a monitor which shows the current actions running in ovirt-engine and tracks their progress. It also capable of presenting completed commands for a period of time. The current design describes tasks monitoring.
[http://ovirt.org/wiki/Features/TaskManager Task Manager feature page](http://ovirt.org/wiki/Features/TaskManager Task Manager feature page)

### Owner

*   Name: [ <NAME>](User:Moti)
    -   Email: <<EMAIL>>
*   Name: [ <NAME>](User:Yair)
    -   Email: <<EMAIL>>
*   GUI Component owner: <NAME> <<EMAIL>>
*   REST Component owner: <NAME> <<EMAIL>>
*   QA Owner: <NAME> <<EMAIL>

### Current status

*   Target Release: 3.1
*   Status: Design Review
*   Last updated date: 21/12/2011

### Detailed Description

A Task Manager is a monitor which shows the current actions running in ovirt-engine server. It provides transparency for the administrator regarding the actions, their progress and status.
The actions will be presented in a Tasks view at the Webadmin, where the status and progress are monitored. The Task Manager will monitor actions and their synchronous and asynchronous tasks.
A simple action describes a command which consists of 2-3 tasks: verification (CanDoAction), execution and possible finalization (endAction). An complex action is:

*   A command which has tasks and invokes additional commands internally which are reported as tasks.
*   A chain of commands depended on each other and monitored in respect to the action which triggered the commands sequence.

A command-task is a meaningful part of the command which the user should be aware of.

The requirements for feature are as follow:
# Providing a mechanism for tasks monitoring via UI (i.e - monitor task status, monitor tasks of given action, tasks of a given entity)

1.  Providing a mechanism for tasks management: stop task, stop all tasks of command, restart of failed command, setting priority for a task. (V2)
    -   The first version will include a default implementation for all commands and specific flow monitoring for the specific commands:
        -   AddVdsCommand
        -   MaintenanceNumberOfVds
        -   RunVmCommand
        -   StopVmCommand

2.  Defining a global correlation-id which spread cross-systems representing an action (Client--> Backend --> VDSM).
3.  Defining a task dependency/task chaining mechanism (Task B will not start before completion of Task A).(V2)
4.  Providing a mechanism to invoke commands asynchronously. (V2)
5.  Defining a "best effort task" - The success of the parent command of this task will not be dependent on the result of a task).(V2)
6.  Providing permission mechanism for the task management.(V2)

The feature will also contain some changes that are required internally for Backend development and to improve task management functionality and correctness of behavior:

1.  Changing serialization of task parameters to JSON - will ease on tasks flow debugging.
2.  Improving task recovery mechanism - in case JBoss restart (there might be a mismatch between last stored task info and the current task status in VDSM).

### Backend

This section describes the backend design for this feature.

#### Entity Description

The following entities/components will be added:

*   **CommandEntity** a representation of a command in the system. Using this entity, a concrete instance of *CommandBase* could be created (e.g. command 'resurrection'). The *CommandEntity* contains list of internal commands which are part of the entire action. Command entity is capable to produce a descriptive tree of tasks which describes an action.
*   **CommandTaskInfo** a representation of a meaningful part of the action. The class could be a parent of other tasks (e.g. task named execution could have beneath it a list of tasks which are part of the execution).
*   **CommandRepository** uses to store and fetch command entities from the database. Also responsible to maintain obsolete entries.
*   **CommandDAO** a DAO interface which defines the DML operations for the command entities.
*   **CommandDAODbFacadeImpl** an implementation of the CommandDAO interface.
*   **GetCommandsQuery** a query which fetches selective or entire command entities from the database.
*   **GetModifiedCommandsQuery** a query which fetches only commands which were updated since a given time. It is designed to pull only tasks which where updated since the last query invoked by a client.

For future use:

*   **CommandSequence** an entity which might compose the *CommandEntity*, representing whether the current command entity is a part of a sequential command (e.g. depended on other commands to be completed before being executed).
*   **SequentialCommandRunnerFactory** a factory which creates a runner for sequential commands.
*   **SequentialCommandRunner** a sequential command runner is responsible to to create a sequence of commands which includes order and dependencies (in the future 'best effort' command could be integrated with the sequence creation process) and to invoke the sequence.
*   **CommandExecuter** an abstraction of command execution method.
*   **SyncCommandExecuter** a synchronous implementation of the *CommandExecuter* interface. Designed to invoke commands synchronously.

##### Enumerators

''' New Enumerators *'
*CommandTaskType'' represents all available task types in the system.

**Updated Enumerators**
*VdcActionType* will be extended with list of categories to which a specific action type belongs to.

##### Annotations

*@NonMonitored* defines which commands should not be monitored. *@CommandName* a descriptive name of the command to be reflect to the user.

##### Main Task Manager Class Diagram

The following class diagrams describe the entities participating in the the Task Manager feature: ![](async-task-main-class-diagram.jpeg "fig:async-task-main-class-diagram.jpeg")
<commit_msg>Updated TaskManagerDetailed<commit_after>---
title: TaskManagerDetailed
category: feature
authors: lpeer, moti, sandrobonazzola
wiki_category: Feature|TaskManager
wiki_title: Features/TaskManagerDetailed
wiki_revision_count: 101
wiki_last_updated: 2015-01-16
---

## Task Manager

### Summary

A Task Manager is a monitor which shows the current actions running in ovirt-engine and tracks their progress. It also capable of presenting completed commands for a period of time. The current design describes tasks monitoring.
[http://ovirt.org/wiki/Features/TaskManager Task Manager feature page](http://ovirt.org/wiki/Features/TaskManager Task Manager feature page)

### Owner

*   Name: [ <NAME>](User:Moti)
    -   Email: <<EMAIL>>
*   Name: [ <NAME>](User:Yair)
    -   Email: <<EMAIL>>
*   GUI Component owner: <NAME> <<EMAIL>>
*   REST Component owner: <NAME> <<EMAIL>>
*   QA Owner: <NAME> <<EMAIL>

### Current status

*   Target Release: 3.1
*   Status: Design Review
*   Last updated date: 21/12/2011

### Detailed Description

A Task Manager is a monitor which shows the current actions running in ovirt-engine server. It provides transparency for the administrator regarding the actions, their progress and status.
The actions will be presented in a Tasks view at the Webadmin, where the status and progress are monitored. The Task Manager will monitor actions and their synchronous and asynchronous tasks.
A simple action describes a command which consists of 2-3 tasks: verification (CanDoAction), execution and possible finalization (endAction). An complex action is:

*   A command which has tasks and invokes additional commands internally which are reported as tasks.
*   A chain of commands depended on each other and monitored in respect to the action which triggered the commands sequence.

A command-task is a meaningful part of the command which the user should be aware of.

The requirements for feature are as follow:
# Providing a mechanism for tasks monitoring via UI (i.e - monitor task status, monitor tasks of given action, tasks of a given entity)

1.  Providing a mechanism for tasks management: stop task, stop all tasks of command, restart of failed command, setting priority for a task. (V2)
    -   The first version will include a default implementation for all commands and specific flow monitoring for the specific commands:
        -   AddVdsCommand
        -   MaintenanceNumberOfVds
        -   RunVmCommand
        -   StopVmCommand

2.  Defining a global correlation-id which spread cross-systems representing an action (Client--> Backend --> VDSM).
3.  Defining a task dependency/task chaining mechanism (Task B will not start before completion of Task A).(V2)
4.  Providing a mechanism to invoke commands asynchronously. (V2)
5.  Defining a "best effort task" - The success of the parent command of this task will not be dependent on the result of a task).(V2)
6.  Providing permission mechanism for the task management.(V2)

The feature will also contain some changes that are required internally for Backend development and to improve task management functionality and correctness of behavior:

1.  Changing serialization of task parameters to JSON - will ease on tasks flow debugging.
2.  Improving task recovery mechanism - in case JBoss restart (there might be a mismatch between last stored task info and the current task status in VDSM).

### Backend

This section describes the backend design for this feature.

#### Entity Description

The following entities/components will be added:

*   **Job** a representation of a client action in the system. Using this entity, a concrete instance of *CommandBase* could be created (e.g. command 'resurrection'). The *Job* contains list of internal steps which are part of the entire Job. Job entity is capable to produce a descriptive tree of steps.
*   **Step** a representation of a meaningful part of the Job. The class could be a parent of other steps (e.g. step named execution could have a list of steps which are part of the job).
*   **JobRepository** used to store and fetch jobs from the database. Also responsible to maintain obsolete jobs.
*   **JobDAO** a DAO interface which defines the DML operations for the Job entities.
*   **JobDAODbFacadeImpl** an implementation of the JobDAO interface.
*   **GetModifiedJobsQuery** a query which fetches only commands which were updated since a given time. It is designed to pull only tasks which where updated since the last query invoked by a client.

##### Enumerators

''' New Enumerators *'
*StepEnum'' represents all available steps in the system.

**Updated Enumerators**
*VdcActionType* will be extended with list of categories to which a specific action type belongs to.

##### Annotations

*@NonMonitored* defines which commands should not be monitored. *@CommandName* a descriptive name of the command to be reflect to the user.

##### Main Task Manager Class Diagram

The following class diagrams describe the entities participating in the the Task Manager feature: ![](async-task-main-class-diagram.jpeg "fig:async-task-main-class-diagram.jpeg")

{'fraction_non_alphanumeric': 0.06371068064688111, 'fraction_numerical': 0.006397725253243291, 'mean_word_length': 4.40067178502879, 'pattern_counts': {'":': 0, '<': 33, '<?xml version=': 0, '>': 35, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4615396', 'n_tokens_mistral': 2827, 'n_tokens_neox': 2703, 'n_words': 1502}