Re: [Engine-devel] Task Manager Design Review

----- Original Message ----- > From: "Mike Kolesnik"<mkolesni(a)redhat.com> > To: "Moti Asayag"<masayag(a)redhat.com> > 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. > i like this one less, because some of the state will be in steps and some in status, it is more confusing for the user and for the developer (for example while implementing a new command, a question may rise if the next call should be step or status), and i don't think it adds anything.