Hi all:
I submitted a pull request to implement realtime output: https://github.com/ansible/ansible/pull/6035/
It implements this feature request: https://github.com/ansible/ansible/issues/3887
Since the proposed patch is large, Michael suggested starting a thread on the mailing list to discuss it. I made an effort to summarize the impact in the pull request comment.
The main use case for this is developing/debugging playbooks when running against a single host. I’ve often run into the case where a task will take an arbitrary long time to complete, and I don’t know whether the task is taking a long time, or whether there was an interactive prompt that popped up that I couldn’t see that has hung the task.
Lorin
This looks awesome! Thanks Lorin.
Thanks for starting a discussion thread over here Lorin.
As I said in my previous post I can see where this might be useful for debugging purposes but I am concerned that the output could become very confusing if it was left turned on in a normal run of multiple tasks on multiple hosts.
Adam
So I also replied on the devel list.
I agree the output may be very confusing for repeated runs and some operations intermediate stdout doesn’t exist, and in many cases there’s no real stdout along the way but it’s reported at the end (currently) so this module would have nothing to pick up.
I’m wondering if a better way (but harder) would be to have a method like “module.real_time_status” etc that it could call along the way for something generic. It might have to write to a different (remote) tempfile, and the async subsystem could pick it up.
This way you could do nice inline updates for some things during an async poll like “10% complete defrobnicating” and so on.
I’m not so worried about confusion when running against multiple hosts, because I don’t see it being used like that. The primary use cases I see are:
- Initial development of playbooks
- Somebody runs a playbook and it gets “stuck”, so they rerun against the stuck host with this option on to see what’s causing a task to not return
The real_time_status approach does sound more elegant. But, as you imply, it would take a lot more effort to implement. I don’t have the cycles to spearhead that effort, but I’d offer moral support to anybody who does.
I do think that if the “run_command” function wrote to temporary files instead of to a pipe, and those temporary filenames could be exposed to the end-user (e.g., when doing -vvvv), that would probably be an 80% solution for debugging. The Ansible user could just ssh to the “stuck” machine and look at those files.
(Yes, this only works for run_command, but I’d wager that the majority of stuck tasks are invoking something that way).
Lorin
Most folks who have been wanting this haven’t wanted it for debug so I’m a bit hesitant to specialize it for that fractional case.
To be honest, we have to greatly reduce the open queue and then look into some needed refactorings before we should attack this.
And I am still very cognizant of this in a multi-host case and architecturally it probably needs new callbacks and may make sense in a UI but the CLI may be a challenge.
It’s interesting but would get us off course.
– Michael
I'd love to see the data on what the use cases are from people who have
requested this feature. Do you have it handy?
Lorin
Just several conversations.
– Michael