How to email all facts

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?

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:

  tasks:
    - shell: echo "$item"
      with_template: >
        {{ hostvars|replace('"', '\"') }}

or maybe making all values jinja templates:

      mail: >
        body="{% filter replace('"', '\"') %}{% include welcome.j2 %}{% endfilter %}"
        subject=welcome

I could make a patch if there is support.

Cheers,
Devin

This bug is now fixed on devel.

Thank you, Daniel; it is indeed.

        -JP

Also, what do you think about allowing inline templates? Like:

  tasks:
    - shell: echo "$item"
      with_template: >
        {{ hostvars|replace('"', '\"') }}

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'll need a minimal example to to reproduce it.

or maybe making all values jinja templates:

      mail: >
        body="{% filter replace('"', '\"') %}{% include welcome.j2 %}{% endfilter %}"
        subject=welcome

I could make a patch if there is support.

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.

I'll need a minimal example to to reproduce it.

A template containing

        "hello

suffices.

Michael DeHaan wrote:

Also, what do you think about allowing inline templates? Like:

  tasks:
    - shell: echo "$item"
      with_template: >
        {{ hostvars|replace('"', '\"') }}

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.

Daniel

Devin Bayer wrote:

Jan-Piet Mens wrote:

There seems to be a problem with indexing `hostvars' in $TEMPLATE().

[1] https://gist.github.com/jpmens/5045984

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.

Daniel

I'll need a minimal example to to reproduce it.

A template containing

        "hello

suffices.

If the $TEMPLATE macro automatically included output in " " and
escaped internal quotes that would fix it for most people.

I can't think of a use where someone would use $TEMPLATE inside a template.

We could essentially make that a "don't do that" scenario.

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.

You mean like this? https://p.6core.net/p/V3bhkFxeAhsoceyP4ZGPCvFk

Not really ...

(Setting args: body: "HELLO" works.
Replacing $TEMPLATE() by $FILE() produces same trace.
)

        -JP

Jan-Piet Mens wrote:

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.

You mean like this? https://p.6core.net/p/V3bhkFxeAhsoceyP4ZGPCvFk

Not really ...

(Setting args: body: "HELLO" works.
Replacing $TEMPLATE() by $FILE() produces same trace.
)

What is in your file? Non-ASCII characters?

Daniel

So there's this story about a guy who goes to a doctor and says "my
arm hurts when I do this", and the doctor says "don't do that then".

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.

What is in your file? Non-ASCII characters?

Plain ASCII.

        https://gist.github.com/jpmens/5045984/raw/b53e7fe94cec694030f22e73b134756581e0b978/mail3.j2

and the doctor says "don't do that then".

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.

        -JP

Jan-Piet Mens wrote:

What is in your file? Non-ASCII characters?

Plain ASCII.

        https://gist.github.com/jpmens/5045984/raw/b53e7fe94cec694030f22e73b134756581e0b978/mail3.j2

Thanks. This should work on devel now, there were some issues with how the
args: were getting transferred that should be fixed now.

Daniel

This should work on devel now, there were some issues with how the
args: were getting transferred that should be fixed now.

Works, thanks.

        -JP

Thanks for all the help and bug-fixes guys. I now have a nice welcome message sent when somebody gets a new box:

https://gist.github.com/akvadrako/5055631

Cheers,
Devin

Cool!

Send me a patch for "nice_yaml" to the "filter plugin" module in core,
and I'll gladly include it.

(Probably to_nice_yaml to be consistent)

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)