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

[Christy Perez]

On Wed, 2014-07-02 at 09:22 -0300, 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.
> 
+1
> > 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
> >>
> >
> 
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel