I've been bitten one too many times by the way that ansible interacts with
jinja. I'd say its error handling is a little bit too lax, defaulting to
return empty strings or similar things that then end up getting my
playbooks to fail later down the line.
To prevent that, I know that I can have a better look at the available vars
and facts gathered with the setup module
ansible -m setup
but often I'd like to see how I can use these with jinja: I'd like to have
a REPL for it (or failing that, a shorter feedback loop)
debug tasks inside a playbook are not ideal also because I cannot use them
to debug issues with templates used before tasks execution (e.g. to define
a variable)
I was thinking of simply using
ansible -m debug -a "msg={{the_jinja_expression_I_want_to_test}}"
but I realized that the output is not quite what I'd expect:
ansible -m debug -a "msg={{hostvars[inventory_hostname]}}"
for example returns
kalivm | success >> {
"msg":
"{'ansible_ssh_host':"
}
and
ansible -m debug -a "msg={{hostvars}}"
prints
kalivm | success >> {
"msg":
"{'kalivm':"
}
It seems to be a truncated json string, probably because not all the
variables have yet been made available there in a simple ansible module
invocation (they'd probably be available in a full playbook run)
Is this known behavior? How do you usually handle these things?
Thanks
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/48fd73fe-98c3-4a16-954d-50c626997fbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
