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

why is ansible's default output not more human readable... stilll? #27078

Closed
imstochastic opened this issue Jul 19, 2017 · 14 comments

Comments

Projects
None yet
@imstochastic
Copy link

commented Jul 19, 2017

ISSUE TYPE
  • Bug Report
COMPONENT NAME

default output plugin? I'm not sure exactly what this is called.

ANSIBLE VERSION

all versions are affected. that's part of the problem.

CONFIGURATION

I'm complaining about an inane default. no configuration problems required

OS / ENVIRONMENT

all

SUMMARY

ansible error output is impossible to read. Why oh why can the JSON output not at least by pretty by default?

STEPS TO REPRODUCE

run any playbook that gives an error

EXPECTED RESULTS

could we have pretty formatting like this:

{
'changed': true,
"cmd": ["rpmbuild", "-ba", "SPECS/thing.spec"],
"delta": "0:00:00.361828",
"stderr":"""
Lots of output
from the program in question
And newlines are interpreted properly!
"""
}

ACTUAL RESULTS

An unreadable JSON dump. I don't think I really need to put an example.

My efforts to push for adoption of ansible in my organization have been thoroughly hindered by this problem - people can't read the error messages they get and so do not use the tool.

You cannot hope to see all the people who are being turned off by this. Most of them simply stop using and go away.

Others (e.g. http://blog.cliffano.com/2014/04/06/human-readable-ansible-playbook-log-output-using-callback-plugin/) have provided acceptable fixes for this with callback plugins (but it absolutely must be the default, or any solution is moot). It is time for this ridiculous problem to be solved. Please please please.

@ansibot

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2017

@imstochastic Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

  • component name

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

click here for bot help

@jhawkesworth

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2017

I had complains about this which went away as soon as I switched to using

stdout_callback=minimal

in my ansible.cfg

@imstochastic

This comment has been minimized.

Copy link
Author

commented Jul 19, 2017

@jhawkesworth yes, that is one way to solve the problem: thanks for pointing that out. One can also install custom callback plugins. But neither solution is in place by default. Which means that people have to know about the solution in question, which means that most people will never implement the solution.

What I'm asserting here is that the default output needs to be easily human readable. Until that change is made, the same thing will keep happening that happened to me: new users that you are trying to bring up to speed will be unaware of how to make the output usable, and will end up walking away with a brand-new "ansible is hard to use" prejudice that you will now have to fight.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

@imstochastic Different people have different needs, personally stdout_callback=minimal is more verbose than the default output. It's not taking care of my limited screen estate.

So what I do is I add more -v's to the commandline if I need more information. Adding a single -v provides jSON output, double -vv gives more context, triple -vvv gives easier readable JSON output.

In most cases, I am not interested in that kind of verbosity, unless I am prototyping/troubleshooting.
So I think this is a sane default.

@jborean93

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2017

Hi!

Thanks very much for your submission to Ansible. It sincerely means a lot to us.

We're not sure this is a bug, and we don't mean for this to be confrontational. Let's explain what we're thinking:

  • The current output level has been part of Ansible for a long time and changing the defaults for this would require substantial support from the community.
  • There are other ways of achieving your desired output like setting the verbosity level through -vvv or adding stdout_callback=minimal to your ansible.cfg

As such, we're going to close this ticket. However, we're open to being corrected, should you wish to discuss. You can stop by one of our two mailing lists
to talk about this and we might be persuaded otherwise.

Comments on closed tickets aren't something we monitor, so if you do disagree with this, a mailing list thread is probably appropriate.

Thank you once again for this and your interest in Ansible!

@jborean93 jborean93 closed this Jul 20, 2017

@jborean93 jborean93 removed the needs_triage label Jul 20, 2017

@bits

This comment has been minimized.

Copy link

commented Feb 9, 2018

Ansible 2.4+ has built-in support for human-readable results:

Temporarily by setting ANSIBLE_STDOUT_CALLBACK=debug in the environment

export ANSIBLE_STDOUT_CALLBACK=debug  # human-readable stdout/stderr results display

or permanently by setting stdout_callback=debug in the [default] section of ansible.cfg

[default]
# human-readable stdout/stderr results display
stdout_callback = debug

@ansibot ansibot added bug and removed bug_report labels Mar 7, 2018

@geerlingguy

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

And Ansible 2.5+ has yaml now too (replace debug with yaml in the above examples if you want to try it out); nice if you still want the structure if you need it for copy/pasting and parsing!

@tristanvvatson

This comment has been minimized.

Copy link

commented Apr 4, 2018

The introduction of YAML as stated by @geerlingguy is indeed excellent, this has allowed me to remove my callback plugins entirely. Write in YAML, read in YAML.

@DimeNastov

This comment has been minimized.

Copy link

commented Jun 12, 2018

I have just tried the yaml option for the stdout_callback, and it is awesome!
I am really grateful to finally have this.

@clintmod

This comment has been minimized.

Copy link

commented Aug 21, 2018

@geerlingguy seems like yaml doesn't work with Ad-Hoc ? I'm seeing output identical to debug

@zoltanmaric

This comment has been minimized.

Copy link

commented Aug 24, 2018

For me this only works if I pass the -v flag. Is there any way to make it work without the -v flag? With it, the output is quite huge because of all the new-lines 😥

@laixintao

This comment has been minimized.

Copy link

commented Oct 26, 2018

@bits [default] not work for me but [defaults] works. Thanks anyway.

@clintmod

This comment has been minimized.

Copy link

commented Oct 29, 2018

Found this in the docs for adhoc: https://docs.ansible.com/ansible/2.5/plugins/callback.html#managing-adhoc

The ansible ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in Ansible Configuration Settings you need to add to use the stdout callback defined above:

[defaults]
bin_ansible_callbacks=True
@ssbarnea

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

Yaml callback is great but it has one PITA kind of bug which I raised at #48170 --- mainly it fails to omit duplicated content for stderr. It does a good job for stdout but not for stderr.

@ansible ansible locked and limited conversation to collaborators Nov 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.