[Kimchi-devel] [Wok][RFC] Manage async tasks.

[Aline Manera]

Hi Peter,

Thanks for the suggestion! I really appreciate that.

But I have some comments to do.
When starting development the user log activity log feature, we haven't 
thought about the operation that generate a Task.
So today, when you create a VM (for example) and it generated the Task, 
the user log will have an entry to say the VM was created but it may not 
be true if the Task later fails.
I have open an issue for that 
https://github.com/kimchi-project/wok/issues/141

The idea to solve that, is to mark a request as "Pending" when it 
generates a Task and only mark it as success or failure after getting 
the final result in the Task.

Said that, probably we can combine user log + task view (I would not say 
task management as today you can not start/stop a Task manually through 
an API or so, we can only see what is going on).

I am open for suggestions and new ideas on how implement that.

Related to the update packages issue, Daniel is working on a solution to 
remove the queue from UI. So it does not conflict with your proposal to 
view the running Tasks and status.

On 07/11/2016 04:11 PM, Peter Pennings wrote:
> Hey guys,
>
> We want to suggest here a new discussion which can maybe turn into a 
> new feature to improve the system.
>
> During the development of some activities involving assincronous 
> tasks, we were thinking about a new way to manage a tasks queue and a 
> new way to get informed about the tasks in the system.
>
> We divided the idea into two parts:
>
> *1-)* First of all, an idea to the backend take care of a tasks queue, 
> allowing the user to trigger tasks as many as he wants. Any request 
> involving an async task triggered by the user, will be pushed into a 
> queue in the back-end. There will be a consumer of this queue, getting 
> the first task to process, and the others will be set with a "Waiting" 
> status. This "consumer" will manage the queue of tasks. One idea to 
> implement this is using the "Publish Subscribe" Desing Pattern. 
> Another idea is to keep the task with a "Waiting" status in the 
> database, and the consumer consumes from this database instead of a 
> queue (updating the status and message of the task).
> At the moment, we don't have a way to control this queue, when it's 
> necessary, the frontend try to do it. The problem is when the user 
> wants to trigger more then one task, then he can't make a logout in 
> the system because he will lose this queue.
>
> *2-)* Develop a new tab in Wok to show the tasks in the system. We can 
> show the tasks for each plugin separeted. For example: if the user has 
> kimchi, ginger and gingerbase installed, this tab will contain three 
> sections, each one with a table of tasks containg the id, status 
> (running, waiting, failure, etc), message and target uri of each task. 
> We can develop a filter for this tables too, allowing the user to 
> search the tasks respecting some filters.
>
>
>
> The main idea with this suggestion, is a way to display what is 
> happening in the system with the async tasks and allow the user to 
> make more then one async request without waiting for the last getting 
> finished.
>
> All of this is just a suggestion, we are open to any doubts or to 
> discuss and improve this idea. Feel free to any suggestions or 
> criticizes. :)
>
> Thank you.
>
> Peter Pennings
>
>
>
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160721/6790a3c6/attachment.html>