Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display Running Tasks #577

Open
marcohald opened this issue Dec 15, 2024 · 4 comments
Open

Display Running Tasks #577

marcohald opened this issue Dec 15, 2024 · 4 comments

Comments

@marcohald
Copy link

marcohald commented Dec 15, 2024

What is the idea ?

It would be great to have and additional Status called "running" for the Tasks in a Playbook.
That is then replaced by the actual result of the Task.
As far as I understand the Plugin Code the state of a Task is only reported when a Task is finished.
It should be possible by adding a request to the api here

def v2_runner_on_start(self, host, task):

My Use-case would be that I have an update playbook that has multiple long running Tasks that tend to hang on some hosts.
It runs with the host_pinned strategy and the output is to crowded to keep an overview on the console.
It would be great if the running status could be filtered like OK or Failed on the WebUI

I'm happy to try to implement it, but I want to hear some Opinions first if that makes Sense

@dmsimard
Copy link
Contributor

dmsimard commented Jan 27, 2025

Hi @marcohald and thanks for the issue.

"running" is already a task status and we have a filter for it here:
Image

Edit: removed self confusion about task status and result status, see my next comment

@dmsimard
Copy link
Contributor

I was a bit tired when I wrote that.. re-reading it now: there is a distinction between the a task status and a task result status.

The "task" is what is running.
This task can have multiple results (as many as there are hosts), these results do not have a "running" status.
This is why there is a filter for the running status for tasks but not for results.

It is a nuance but hopefully that makes sense.

With that in mind, I think I understand the initial request better: you would like ara to create the result as running, then have ara update it when it knows the real status.

It would mean an extra API call for every task/host result so it doesn't come for free.
Perhaps we could better highlight that there is a task running for which we have not yet received all the results for or something like that.

Worth thinking about.

@marcohald
Copy link
Author

The "task" is what is running.
This task can have multiple results (as many as there are hosts), these results do not have a "running" status.
This is why there is a filter for the running status for tasks

Didn't know that there is a difference between the "tasks" and the "results" of them.

Perhaps we could better highlight that there is a task running for which we have not yet received all the results for or something like that.

Maybe a Link on the Results Page of the Playbook that goes to the Tasks view with a Filter for the running state and the executed playbook instance.

When i click on Tasks and then on the Report Button of a Running Task it has for example the link http://127.0.0.1:8000/playbooks/16.html?task=108#results
But the Link displays the just the empty Playbook Task List, as there is no "task result" yet if I understood it correctly.

It would mean an extra API call for every task/host result so it doesn't come for free.

But not necessarily on the Client side, the Server could just create the Task Result with state running when it receives the Task in the Running state.
But it is additional overhead, so it maybe should be disabled as default?

@Hipska
Copy link

Hipska commented Jan 28, 2025

Yeah, I also think it makes sense to have this option, so you know which task is currently being worked on.

Of course as opt-in because of the overhead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants