on_task_stop callback in CallbackBase ?

Hi all,

I recently found the strength to start trying to contribute the Ansible project, please excuse my knowledge.

I was looking at the profile_tasks callback and saw that the time displayed after each tasks is in fact the time spent in the previous one.
I saw that it comes from the fact that there are not stop callback in the CallbackBase class.

Could someone explain or redirect me to a site/blog/paper explaining why we don’t have any stop callback like v2_playbook_on_task_stop ?

Thank you very much.

I don’t know of a site/blog/paper explaining the callback events.

I guess there wasn’t much need for it when callback plugins were created, given that straight after one task has completed the next task will start (usually, possibly not if you are using the debug strategy), until you run out of tasks. So perhaps there was not much need to generate an event for the task stop.

I think the intention of callback plugins was mostly for changing what ansible outputs.

Jon

Hi Jon,

Thanks for the feedback.
My issue with the current callback is that if you want to publish stats on execution time, you are able to publish something only in the start callback, which is kind of broken because you 'll publish a value which is out of context because you want to publish a task/play duration at the end of it, not at the start of the next one. (because in the next one, the task/play name is not the good one anymore).

Can someone orient me in the code where the callback are fired ? maybe it isn’t difficult to add the stop callbacks ?

Thank you.
Regards

If I recall, the other profiling plugins just capture execution time and then report in the on_stats event at the end of the playbook run.

I don’t know the code well enough to tell what it would take to add more events, sorry.

Jon

There are existing profile plugins, which just use the task start and
play stats. This is because the 'stop' cannot really be determined
with the task as there is no 'hard stop' as we don't keep track of
draining of hosts for specific tasks.

The iterator just returns task/host tuples. In linear strategy we can
detect in 'task start event' if the task has changed and that is what
profilers use to detect the 'previous task end', with play stats being
the place where the 'last task ends'.