[Ovirt-devel] Re: Thoughts about taskomatic redesign

[David Lutterkort]

On Fri, 2008-06-27 at 10:24 -0400, Scott Seago wrote:
> David Lutterkort wrote:
> > On Wed, 2008-06-25 at 18:32 -0700, Ian Main wrote:
> > 
> What we _don't_ have in the current implementation is:
>   1) any notion of task dependencies (i.e. task 66 must run after 
> 33,44,and 55 have completed. 33 and 44 must complete successfully, but 
> success state of 55 is unimportant)

Are optional dependencies really needed ? I would just stick with hard
dependencies if at all possible.

>   2) any notion of compound tasks (i.e. task 100 is composed of subtasks 
> 101,102,and 103. These subtasks have their own dependencies and are 
> tracked just as top-level tasks, and task 100 is essentialy a no-op task 
> with dependencies on its subtasks

Probably another thing that's best left as 'future work'. From your
description of existing tasks, it seems that keeping them close to the
WUI interaction is probably the simplest for now.

> We may not need two-level queuing, but generating the dependency graph 
> will have to happen at one step -- "order the tasks" as stated above 
> will still be necessary, but it's more a case of "work out the 
> dependencies for each task".

Unless it's needed for some spiffy display in the WUI, there's really no
reason to ever handle the dependency graph as a whole. All you need are
ways to pick out 'runnable' tasks and/or find existing tasks that a new
task may depend on.

>  When the WUI insterts a task for "create 
> this VM" or "migrate this VM" the dependency information will not be 
> known by the WUI. So something on the taskomatic side will have to, as 
> part of the "notice new tasks in the queue and process them"

That's an important point and reason to separate the task queueing logic
a little more from the WUI, so that instead of just creating and saving
a new task object to the DB, you actually have some sort of API for
adding new tasks, and the implementation of the API knows what possible
dependencies and prerequisites to look for for each task.

That API would probably also be the right one to expose publically.

David