Re: [Engine-devel] Task Manager Design Review

From: "Mike Kolesnik" <mkolesni(a)redhat.com&gt; To: "Moti Asayag" <masayag(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Monday, January 2, 2012 5:02:22 PM Subject: Re: [Engine-devel] Task Manager Design Review 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_Invocat... > 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 _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel