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