[Kimchi-devel] [RFC] [Wok] Issue 141 - Track asynchronous tasks in user request log

[Lucio Correia]

On 22-08-2016 15:29, Aline Manera wrote:
>
>
> On 08/22/2016 02:39 PM, Lucio Correia wrote:
>> On 22-08-2016 13:52, Aline Manera wrote:
>>> Hi Lucio,
>>
>> Hi,
>>
>>>
>>> Task is an internal mechanism to Wok and its plugins execute long time
>>> processing. So that is not part of user knowledge.
>> User log functionality is for admins, not regular users, right?
>
> Correct. But even though an admin does not know how the backend works.
> He/she only wants to know which actions were taken in the system.
>

I think it's important for him/her to know how much time a task is 
taking, and which other requests were done between the start and end of 
it. My proposal covers it.

>>
>>> Adding a log record as Task will make the user confused IMO.
>>
>> I don't think so, have you seen my patches running? I've changed the
>> UI too. It's pretty clear IMHO.
>>
>
> No! I am concerned about the backend part by now.
>
Yes, you can use the backend to download the log file as well. It's a 
working example of this RFC.


>>>
>>> So my proposal is: when the Task is started in the backend, add a log
>>> record and set its status as 'pending'
>>> Once the Task is completed (with success or not), change the log record
>>> to success or failure according to what happened there.
>>>
>>> To do that you will need to find a way to query a log entry in the JSON
>>> file and edit/replace it to the updated entry.
>>>
>>> What do you think about it?
>>
>> To do that we will also need to differentiate in wok/control/base.py
>> the type of request (if it generates task or not) and I tried to avoid
>> that with my design.
>>
>
> It is already done in the control/base.py.
>
> Look for generate_action_handler_task() function in control/base.py
> All the actions which rely on Task are done by this function.
>

That's not correct.

I'm tracking AsyncTask instances. Severeal POST requests on collections 
generate an AsyncTask (Kimchi examples: create storage volume, create 
guest, etc.). Others don't. They will need to be differentiated as I told.

On the other side, not all APIs handled by 
generate_action_handler_task() use AsyncTask instance, and will also 
need to be differentiated, increasing code complexity.

Kimchi examples for generate_action_handler_task():
do not generate AsyncTask: restart guest, shutdown guest....
generate AsyncTask: migrate guest, clone guest


>> Also, I believe the way I proposed to do it makes it more clear for
>> the guy debugging through logs what's happening behind the scenes.
>>
>
> This feature is not for debug! It is for an admin identifies which
> actions were taken in the system in a visual way.
>
Let's say analysis instead of debug. It's good to know how much time a 
task took to finish, and which other requests/tasks were run meanwhile.


>> So, IMHO, it will increase code complexity to differentiate tasks
>> through some variable, handle it in base.py, code for changing log
>> entries, for no real gain.
>>
>>
>>>
>>> Regards,
>>> Aline Manera
>>>
>>
>> Regards,
>>
>


-- 
Lucio Correia
Software Engineer
IBM LTC Brazil