The reason I wanted this was to be able to quickly see the effect of variable changes I made and verify that the precedence was as I intended it to be. I think with a reasonable complex groups+host+roles mix this would also help as one could visually verify/compare the different configurations from the variables.
A sample output based on 2 plays and 1 group consisting of two hosts. The ‘debug’ play consists of two roles, with variable definitions from the roles, host_vars and the play itself : https://gist.github.com/alisaifee/ce80f1a739c780d60754
There were concerns about the yamlc implementation in the pull requests - I’m not intimately familiar with pyyaml and did that almost entirely based on the example at http://pyyaml.org/browser/pyyaml/trunk/examples/yaml-hl/yaml_hl.py. Having said that, coloring the output isn’t necessary, just a good to have. I did try using a pretty printed python dictionary, but yaml ended up looking much cleaner
Removing yamlc I think makes the code a lot cleaner.
Limiting option sprawl is also important to me, i.e. there should not be a very large number of ansible-playbook options.
My general concern is how this output scales when there are a very large number of hosts, but this may be acceptable if in a -vvv mode or possibly even -vv
I also have some concerns that due to operation of the play, in fact that variables can change in the middle of the play, including taking facts and other things, this implementation in /usr/bin/ansible-playbook is probably not comprehensive enough and would end up raising a fair amount of support questions. That is, I think this generally works for basic playbooks.
Removing yamlc is just fine by me - I mostly added that in to stay with the ‘we like colors’ theme of ansible (+ I like them as well)
Using the -vvv option sounds interesting though would incur the cost of actually running the playbook and connecting to the hosts (good & bad, since more information can be made available if facts are gathered).
The volume of data being printed in -vvv mode (whether its printed only once at the beginning of the play or per task) will definitely be a problem though. Also, in that mode, a pretty printed yaml won’t make sense anymore and json might be better suited. Being able to limit the variables that are being displayed then (maybe by specifying the paths to the root variable(s)) is one idea that might help with managing the verbosity.
Slight tangent, in the implementation I’d sent a pull request for - I was evaluating the ‘final variables’ as combine_vars(play.vars, inventory.get_variables(host)). is this correct ?
" I was evaluating the ‘final variables’ as combine_vars(play.vars, inventory.get_variables(host)). is this correct ?"
Actually no.
The theme we are going for is really things that show information about playbook or runner code should be evaluated by playbook and runner code, that way /usr/bin/ansible* does not acquire separate simulations of business logic.
It’s missing a lot of things calculated by Runner code (which includes about 10 extra variables, among other subtle things), which is why I am not wanting to include this at this time.
(AKA, ansible code is the best evaluator of ansible things)
(+ I like them as well)