[Engine-devel] Task Manager Design Review

[Itamar Heim]

On 01/02/2012 06:25 PM, Omer Frenkel wrote:
>
>
> ----- Original Message -----
>> From: "Mike Kolesnik"<mkolesni at redhat.com>
>> To: "Moti Asayag"<masayag at redhat.com>
>> Cc: engine-devel at 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_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.
>>
>
> 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.

but every external step may have sub status changes (say, disk creation 
progress bar, or delete vs. wipe after delete steps, etc.)