[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