[Engine-devel] Task Manager Design Review

[Moti Asayag]

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

> 
>> 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.
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel