For my "email facts" I still have one problem. How do I handle double quotes in the output?
If my template is: ( "words ) the mail module complains rightfully: ValueError: No closing quotation. So can I escape the template output in my playbook?
Also, what do you think about allowing inline templates? Like:
One goal of Ansible is to be readable like pseudocode, so I'd rather
not have this, it's a slippery slope.
That all being said, I also disagree that it complains rightfully, I
believe it complains non-rightfully, and that the $TEMPLATE macro
needs to escape quotes when it needs to.
I'd rather not -- using Jinja2 inside of the playbook is not a good
idea, because it quickly turns our templating to Perlishness IMHO.
I'd rather fix the root cause.
One goal of Ansible is to be readable like pseudocode, so I'd rather
not have this, it's a slippery slope.
That all being said, I also disagree that it complains rightfully, I
believe it complains non-rightfully, and that the $TEMPLATE macro
needs to escape quotes when it needs to.
It doesn't know whether you are using ' or ", or if you even want quotes.
Maybe you are using $TEMPLATE to invoke some Jinja2 to generate your entire
action line, in which case messing with the quotes would break it.
For the record: Daniel says I'm missing a "name:" on the action. Adding
that indeed fixes the problem, but I think that's a bug, as 'name:' is
supposed to be optional. (Gist updated with a comment.)
This bug is now fixed on devel.
Thanks Daniel! This was my problem too!
For my "email facts" I still have one problem. How do I handle double
quotes in the output?
Best way to get out of quote-hell is to use the new args: way of specifying
arguments. This means you can include anything you want, and ansible will
take care of quoting for you.
Best way to get out of quote-hell is to use the new args: way of specifying
arguments. This means you can include anything you want, and ansible will
take care of quoting for you.
Best way to get out of quote-hell is to use the new args: way of
specifying
arguments. This means you can include anything you want, and ansible
will
take care of quoting for you.
So you're saying if stuff which is documented breaks, we shouldn't use
it? Am I getting this right?
Easiest way to see hostvars is to just write it to the local server
with "template"
{{ hostvars | to_json }}
and use the fetch module to pull it back if you want.
Well, that's one way, yes. We could also shell out and lpr it. (Pardon
the sarcasm.)
I chipped in because I thought OP's request wasn't a bad idea. I'll
stand down if this is OT. My intention, in posting bug reports, is to
improve on the quality of stuff.
Nice, that's what I wrote the mail module initially for.
The other (slightly evil) use-case was to nag other teams if our process depended on their (non-automated) intervention(s). Our playbook would bail-out while sending the email (again) until the matter was cleared and we could continue the process.
(Read: complex processes in a large enterprise environment)