[Engine-devel] Task Manager Design Review

[Mike Kolesnik]

Original Message -----
> On 01/02/2012 11:05 AM, Yair Zaslavsky wrote:
> > On 01/02/2012 10:12 AM, Moti Asayag wrote:
> >> On 01/02/2012 09:53 AM, Itamar Heim wrote:
> >>> On 01/02/2012 02:02 AM, Moti Asayag wrote:
> >>> ...
> >>>
> >>>>>
> >>>>> 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).
> >>>
> >>> I think SPM election/status is an interesting enough task that if
> >>> it
> >>> happens it should be documented (as well as its process/results).
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>> 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.
> >>>
> >>> oh - I thought a job is pre-defined with its steps, then the
> >>> backend
> >>> runs them.
> >>> from your reply i understand the job/steps are just documentation
> >>> of
> >>> what already happened?
> > Actually, also of what is already happening, If I understand
> > correctly.
> Correct.
> See
> http://ovirt.org/wiki/Features/TaskManagerDetailed#Simple_Command_Invocation_Sequence_Diagram
> 

I think, as I said in the design review meeting, that having each job be broken down to 2-3 steps of: validation, execution, finalization is too verbose for the user of the UI.
I believe this can all be encapsulated in a status field for the job.

Of course, steps which represent a "child job" invocation are still logically perfect - the parent job will be in state "executing" and the child job will have it's own representation with the correct state.

> > 
> >> Correct. The Command implementation will determine by code when to
> >> add a
> >> step and how to decide it ended. A default implementation is
> >> provided
> >> for all commands, except those which specified on the requirements
> >> to be
> >> more detailed.
> >>
> >> Doing the other way (let the flow definition execute the steps)
> >> means
> >> implementing a business process manager (or using existing one -
> >> such as
> >> jBPM). I don't think the backend as implemented now is capable of
> >> adjusting to it and letting external service orchestrate the flow.
> >>
> 


Regards,
Mike