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

Christy Perez christy at linux.vnet.ibm.com
Thu Jul 3 15:09:29 UTC 2014



On 07/03/2014 05:31 AM, Wen Wang wrote:
> On 7/3/2014 6:06 PM, Yu Xin Huo wrote:
>> For this RFC, we are trying to create a *generic message notification
>> component* to handle *long task*.
>>
>> I do not think any new tab is needed for message subscribe configuration.
>>
>> If this long task is at console admin
>> level(host/template/network/storage pool), I recommend to share this
>> message among all *root* users.
>> If this long task is at VM level, only *VM users* got this message.
>>
>> The task should be identified by the uri(web api) that triggered it.
> +1

>From what I understand, only messages attached to kimchi tasks are going
to be accepted? What about handing up messages from libvirt about errors
in a VM? For example,
https://github.com/kimchi-project/kimchi/issues/367. Or is this
considered a "long task at VM level" too?


>>
>> On 6/27/2014 7:15 PM, 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.
>>>
>>> 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
> 
> 
> 
> 
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> 




More information about the Kimchi-devel mailing list