[Engine-devel] Task Manager Design Review

[Moti Asayag]

On 01/01/2012 11:38 PM, Itamar Heim wrote:
> On 01/01/2012 02:39 AM, Moti Asayag wrote:
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> looks pretty comprehensive - a few questions:
> 1. can one see all audit log events related to a task?
It means to apply a search query for the event log by job id.
The job id is associated with the audit log, therefore such query could
be comprised. This will probably be enabled from the global Tasks view.

> 
> 2. "A command with VDSM tasks" - what about other types of tasks? what
> if after the vdsm tasks there is another part of logic, then another
> vdsm task (iirc, there was a legacy limitation of "one single async task
> in the end of the command", but this shouldn't be relevant any more).
The Step entity is associated with external_system_type and external_id
which in this case are correlated to VDSM (external system type) and
VDSM task id (external id).
Having additional external systems which the backend invokes tasks on
will be supported if the task on the external system could be associated
with its representing Step and the task could be queried for it status.

VDSM Tasks which are created by a command will be polled only after the
command execution is over. If the command failed in between the creation
of Tasks due to some runtime exception, the command should be
rolled-back and the VDSM tasks should be cancelled and cleared. If
execution ends, by polling VDSM task status the step representing each
task should be updated with the task status. An example for such command
is HibernateVmCommand.


> 
> 3. "A command which invokes internal commands - By default, the internal
> command will not be presented as a step of the parent command."
> 
> examples of the non default behavior?
For example the MaintenanceNumberOfVdsCommand which invokes
MaintenanceVdsCommand which invokes InternalMigrateVmCommand.
Those are significant steps which we should expose to the user.

> 
> 4. "A customized command - an asynchronous job which its termination is
> decided by an event other than tasks. There are few types of scenarios
> for it"
> the examples are all described as internal implementation details - what
> are some actual relevant use cases/flows and what will the user see for
> them?
> 
> you also mention AddVdsCommand here - will it's internal steps be
> visible to the user as part of the monitored task?
AddVdsCommand is an example for the above as its execution is durable
due to the installation part that should be exposed as a step to the user.

Another example is the determination of completing the
MaintenanceVdsCommand by receiving an event from the host monitor for
host moved to maintenance. It is already a step created earlier, but its
completion will be due to this specific event.


> 
> 5. requirements: what about internal tasks originated by the system (SPM
> election, live migration due to load balancing, fencing taking place,
> refresh of users from a directory, etc.)?
It was discussed on the meeting held today. It was agreed to report for
specific internal action such as VM migration, Host fencing,... but not
for the event itself (in order to prevent from flooding the Tasks view
from frequent events).

> 
> 
> 6. STEP table, start_time is "not null" - shouldn't it be nullable?
No. The Step is created in adjust to the execution unit it describes. In
order to prevent from additional update, it should be created with
status Started and start time.

> 
> 7. UX - no main tasks view?
Eldan, Einav ?

> 
> 8. can i define a step based on a previous step failure rather than
> success (i.e., step 2 will be run only if step 1 succeeds, step 3 will
> only run if step 1 failed, step 4 could be either dependent on any of
> them, or run after step 2 and 3 finished, whatever their result was.
It requires introducing the "best effort step" (V2), a failure of a step
will not fail the entire job. Mixing it with customized command should
provide that behavior. However, the Steps are used to report on
execution units status and do not participate in handling the flow.

> 
> 9. REST API modeling?
On the way...
>