[RFC] Improve task management for kimchi
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
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?
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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. 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 7/2/2014 8:22 PM, 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.
From my point of view, it will probably confuse the user to have an additional tab just for register the message user want to know. It's better that Kimchi decide which message one certain role needs to know and register this kind of message to user. We might need to define the roles first
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/01/2014 11:04 PM, 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?
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 06/27/2014 07: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. Now let me elaborate above.
For Browser, it can be an event loop worker. It can subscribe event message that users care to the back end broker. listen the events from the broker and take some action for the event. For back: The broker should collect and store the events from everywhere. The broker should dispatch the message to the client who subscribes it. For some event, broker should determined whether it should dispatch to user. Such a VM shutdown event, the broker just send it to the user who has the access permission. (Yu Xing's suggestion) We had better define the event message format. We had better to find an existing python lib for it. If no we should code it for ourself. [ client1 ] care VM | ^ libvirt event -------------\ shutdown | | VM shutdown \ V | event 1 -------- -------------------------->[ broker ] / ^ | dispatch event 2 ------------/ | | subscribe | V listen [ client2 ] For websocket: There's also an issue about it. https://github.com/kimchi-project/kimchi/issues/22 The websocket is the pipe to connect the broker of the UI event worker. We should support websocket proxying directly from the cherrypy server on its given port. Zheng Sheng is working on it. It can work on cherrypy. Seems something wrong with nginx.
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On 7/2/2014 11:06 PM, Sheldon wrote:
On 06/27/2014 07: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. Now let me elaborate above.
For Browser, it can be an event loop worker. It can subscribe event message that users care to the back end broker. listen the events from the broker and take some action for the event.
For back: The broker should collect and store the events from everywhere. The broker should dispatch the message to the client who subscribes it. For some event, broker should determined whether it should dispatch to user. Such a VM shutdown event, the broker just send it to the user who has the access permission. (Yu Xing's suggestion) We had better define the event message format.
We had better to find an existing python lib for it. If no we should code it for ourself. [ client1 ] care VM | ^ libvirt event -------------\ shutdown | | VM shutdown \ V | event 1 -------- -------------------------->[ broker ] / ^ | dispatch event 2 ------------/ | | subscribe | V listen [ client2 ]
For websocket: There's also an issue about it. https://github.com/kimchi-project/kimchi/issues/22 The websocket is the pipe to connect the broker of the UI event worker. We should support websocket proxying directly from the cherrypy server on its given port. Zheng Sheng is working on it. It can work on cherrypy. Seems something wrong with nginx.
Thanks Sheldon, as we discussed yesterday on scrum meeting, it's better to use the socket method solve long time task problem. We wanted to make this feature a generic one so that every long-time task will benefit from it. I think Kimchi should use the user information alongside with task type to decide which user(s) we should send the message to. It all happen when automatically. I don't think we need the message management for users. Also, do we need to change all the tasks to this socket pattern or just for long-time tasks? I recommend long-time tasks. For the message format, I think we might need the user name, role and the url to indicate which kind of task we are running. As you said , the broker filter the message from the backend and I might need to know your design for the message frontend gets. We need to have it discussed further more.
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
I have one concern of using the websocket. Do we need another port for the socket. If so, we might need to take the security issue into consideration. Do we have some methods that prevent these insecure scenarios? On 7/2/2014 11:06 PM, Sheldon wrote:
On 06/27/2014 07: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. Now let me elaborate above.
For Browser, it can be an event loop worker. It can subscribe event message that users care to the back end broker. listen the events from the broker and take some action for the event.
For back: The broker should collect and store the events from everywhere. The broker should dispatch the message to the client who subscribes it. For some event, broker should determined whether it should dispatch to user. Such a VM shutdown event, the broker just send it to the user who has the access permission. (Yu Xing's suggestion) We had better define the event message format.
We had better to find an existing python lib for it. If no we should code it for ourself. [ client1 ] care VM | ^ libvirt event -------------\ shutdown | | VM shutdown \ V | event 1 -------- -------------------------->[ broker ] / ^ | dispatch event 2 ------------/ | | subscribe | V listen [ client2 ]
For websocket: There's also an issue about it. https://github.com/kimchi-project/kimchi/issues/22 The websocket is the pipe to connect the broker of the UI event worker. We should support websocket proxying directly from the cherrypy server on its given port. Zheng Sheng is working on it. It can work on cherrypy. Seems something wrong with nginx.
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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. 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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?
If I understand correctly, this error is generated automatically from backend, there is no task associated with it and not a long task. But we are creating a generic messaging component, although it is not a long task, it can also leverage this feature. 1. Backend generate an error. 2. Get which VM this error from. 3. Get users that have access to this VM. 4. Push the message back to clients with web socket.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/03/2014 07:06 AM, 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 About the design, to accomplish that will we use websocket or broker or ..?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 7/3/2014 9:39 PM, Aline Manera wrote:
On 07/03/2014 07:06 AM, 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
About the design, to accomplish that will we use websocket or broker or ..?
According to Sheldon, we should use broker to receive message from the server and the browser need to use websocket to connect the broker for the messages. The browser will use web worker to finish the job. There is one more thing to be noticed that web worker and websocket are supported by HTML5 and IE 10+, if we are going to adopt this technology, we might have to change the supported IE version from 9+ to 10+ in Kimchi.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 7/3/2014 9:39 PM, Aline Manersa wrote:
On 07/03/2014 07:06 AM, 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
About the design, to accomplish that will we use websocket or broker or ..?
with web socket, below 2 are the unique value. 1. the notification can be initialized from backend. https://github.com/kimchi-project/kimchi/issues/367 from Christy 2. save client from query task status with a 200ms interval. if only for long task, web socket is not a must. Would like to listen to team's voice to have more opinions. for broker, it is not technological, it is a logical component to distribute tasks to users and push back to client.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (5)
-
Aline Manera -
Christy Perez -
Sheldon -
Wen Wang -
Yu Xin Huo