Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
why is ansible's default output not more human readable... stilll? #27078
default output plugin? I'm not sure exactly what this is called.
all versions are affected. that's part of the problem.
I'm complaining about an inane default. no configuration problems required
OS / ENVIRONMENT
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
could we have pretty formatting like this:
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.
@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:
Please set the description of this issue with this template:
@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.
@imstochastic Different people have different needs, personally
So what I do is I add more
In most cases, I am not interested in that kind of verbosity, unless I am prototyping/troubleshooting.
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:
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
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!
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
Found this in the docs for adhoc: https://docs.ansible.com/ansible/2.5/plugins/callback.html#managing-adhoc