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

[Peter Pennings]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160711/202e59e5/attachment.html>