3:53 a.m.
On 7/3/2014 11:09 PM, Christy Perez wrote:
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?
Good point! I thought the
intention has been changed about we using
websocket right now. Users should know what happened to their VMs which
could not be accomplished by querying the status from the browser. It is
a good feature to solve asynchronous errors triggered by the back-end.
So using websocket now is mainly for those message that could hardly
catch by the browser. As for the long-time task, we can use the
mechanism of of the websocket that save the browser's effort of querying
every 200ms for the up-to-date status of the tasks.
>> 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(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
>
>
>
> _______________________________________________
> 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