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

Aline Manera alinefm at linux.vnet.ibm.com
Wed Jul 2 12:22:59 UTC 2014


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.

> 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/20140702/c2d1b685/attachment.html>


More information about the Kimchi-devel mailing list