willthames
commented
6 years ago I wonder if we could achieve something like
--verbose:print_results
--verbose:pretty_print_results
--verbose:invocation
--verbose:variable_loadingetc, and then have various verbosity levels map to a subset of those (at the moment print_results is -v whereas pretty_print_results is -vvv - sometimes I'd like pretty_print_results without having the rest of -vvv)
With that kind of mechanism, something like --verbose:run_debug_level=3 might be possible.
dagwieers
Proposal: Add Verbosity Level/Switch for Displaying Programmatic debugs only without the Additional Output Bloat from Ansible's -v behavior.
Author: Douglas Wagner<@Illydth>
Date: 2018/02/02
Motivation
Ansible "debug" messages have a "verbosity" level they can be set at to only show during a specific verbosity. However, each verbosity level adds additional information to the base of what is displayed on the console...and for sufficiently complex playbooks can lead to a lot of "extra" information.
There is no verbosity level or command line switch that will JUST display debugs I am intentionally putting into my code.
In other words, I want to be able to run ansible/ansible-playbook in a way in which I don't get the debugs in my code (current behavior: debug verbosity 1 or higher). I ALSO want to be able to run ansible/ansible-playbook and get the debugs in my code WITHOUT any additional ansible debugging messages / output at the command line.
Basically, for this simple playbook:
There is no way to avoid printing myPath on a normal execution of the playbook while still allowing some way to print "myPath" when I am attempting to debug the code without adding "verbosity: 1" and then seeing a bunch of extra output on the command line.
Problems
What problems exist that this proposal will solve?
There is no good solution for printing debug messages in an ansible playbook without adding a large amount of immaterial information to the command line output.
When trying to put debugging information into an ansible playbook, the user has only 2 options: 1) Add -debug plays to the code and have them output all the time. - This increases the size of the output (sometimes expansively) and causes general non-debug runs of a playbook to be bloated in output with lots of un-needed information. 2) Add -debug plays using "verbosity: 1" or above forcing you to use "-v" on the command line to show those debug messages. Unfortunately this also produces un-needed ansible output from a playbook run since -v also starts showing things like standard out returns from commands.
When trying to debug a sufficiently complex ansible playbooks, programmers are in a damned-if-you-do/damned-if-you-don't scenario: Either choosing to clutter up their non-debug output or choosing to over-complicate their attempts to debug their own code.
The only other option is to go in and comment/uncomment debug lines every time you want to change the way the scripts run which is a really bad practice in a code-controlled environment.
Solution proposal
There are two possible ways of solving this issue, either works:
1) Change verbosity such that adding a single "-v" to the command line produces identical behavior to not using the -v. This provides an ability for ansible programmers to use "verbosity: 1" in their code to hide debug variables during normal runs and turn on debug variables for debugging runs. Each "verbosity level" would then attain an additional "v"...so -vv would act the same as the current -v, -vvv would act the same as the current -vv and so on.
2) Add an additional command line switch to ansible and ansible-playbook commands to turn on "user debug". "Verbosity" in the debug module could then become a "true/false" variable: "True" for the debug printed all the time and "false" for the debug printed only when the new command line switch is added.
As an additional benefit, ansible module developers could also hook this command line switch to allow their own modules to turn on or off code as needed. Imagine an instrumentation addition to ansible which would print the times it took for each section of the code to run which could be turned on with this switch (for instance). Module developers would have the option to develop sections of a module or entire modules around providing more information or doing extra things without a performance hit in a "real" environment execution.
Dependencies (optional)
At this moment, the "Debug" module would probably need to be re-tooled to support this method of "turning on" debugs instead of the current "verbosity" method.
Documentation (optional)
Anything else?
IMHO most other languages have some method by which to "turn on" debugging within the language without code modification. C's "#IfDef" is a good example (though that's a compile time option) of how the behavior of turning on/off debugs is useful.
It's very common practice for languages to allow programmers to architect "clean" production runs of their code while still allowing "informative" debug runs during problem diagnosis sessions. The current "verbosity" / "-v" enablement is a good first step in this, but causes unnecessary feedback from Ansible's output, at times actually making it harder to debug a problem that's being experienced.
The root of this proposal is a way by which to put -debug messages into the code and have them execute only at times I want them to execute, without significantly bloating ansible's output on the command line. The details above are only a suggested way of implementing the behavior and may not be the best way. The importance of the proposal is the capability, not the method.