[Kimchi-devel] [RFC] Improve task management for kimchi

[Wen Wang]

On 7/2/2014 8:22 PM, Aline Manera wrote:
>
> On 07/02/2014 06:31 AM, Wen Wang wrote:
>> On 7/2/2014 10:04 AM, Aline Manera wrote:
>>>
>>> On 06/27/2014 08:15 AM, Wen Wang wrote:
>>>> Dear all,
>>>> *
>>>> **Problems:*
>>>> Now our strategy  for long time operation is using task which the 
>>>> browser needs to check up-to-date task status time by time until 
>>>> the task ends. It's time consuming and less efficient. Also there 
>>>> exists several problems when locating each task when doing debug 
>>>> generating and storage pool as well as some new features that might 
>>>> use task strategy in the future.
>>>>
>>>> *Solution*:
>>>> As talked with Sheldon and Zhengsheng, we came up with a solution 
>>>> that avoid browser checking status every 200ms. Also, we might need 
>>>> some more labels in each task to provide more information when 
>>>> getting the task like we might need to indicate which operation 
>>>> triggered certain task. What's in our mind is to use the strategy 
>>>> that allow the server inform browser about the task information. 
>>>> Our proposal is designed as follows.
>>>>
>>>> 1) Browser needs to register to the back end to indicate which part 
>>>> the result needs to reply to when the task finished.
>>>> 2) The back end use broker to manage message distribution: when a 
>>>> task is finished or experiencing an error, back end inform the 
>>>> browser certain part of work is finished or error.
>>>> 3) Using websocket of cherrypy to accomplish the message transfer.
>>>>
>>>
>>> +1
>>>
>>> We just need more details to accomplish that
>>> Can we do it in 3 weeks (1 sprint)? or 1 sprint for backend and 
>>> other one for the frontend?
>> We discussed today.It depends on how much we want to use this new 
>> feature. Though it's a good feature, we might need to redesign all 
>> task in the back-end and might need a new tab in the front which 
>> indicates user what kind of message they want to register. 
>
> A new tab to register for messages??
> I don't think so. The frontend (ie, our JS code) should be enough 
> expert to do it by itself. It should not require any user interaction.
 From my point of view, it will probably confuse the user to have an 
additional tab just for register the message user want to know. It's 
better that Kimchi decide which message one certain role needs to know 
and register this kind of message to user. We might need to define the 
roles first
>
>> Also just for the task issue, simply we might just need to add some 
>> pairs of keys that provide more information of the task so that the 
>> browser will identify which user is running which tasks, in which 
>> case, we still need the browser check over and over again whether one 
>> task is finished.
>>
>> We might need to discuss more about this issue and if we want a new 
>> design of the message deliver, it might need more time for both the 
>> back-end and the front-end work for a long time since there hardly 
>> exist one good solution for that. We need to design all my our own. 
>> And for the task improvement proposal, it should be a much more quick 
>> job.
>>
>> Best Regards
>>
>> Wang Wen
>>>
>>>> Best Regards
>>>>
>>>> Wang Wen
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140703/9aabd0a8/attachment.html>