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

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(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel