I'm not positive it's going away, but you can use conditionals in a template, technically, if that helps you out.
On Sun, Oct 5, 2014 at 7:41 PM, Alexandr Kurilin <[email protected]> wrote: > Assuming copy content goes away, is there any way to simplify the template > module? Right now if I want to copy a PEM cert from the vault onto a target > host, I have to create a set of files such as cert.j2 and key.j2 with > contents {{ cert }} and {{ key }} respectively, so now I have to manage two > additional files in my repo. > > > On Monday, September 29, 2014 3:15:27 PM UTC-7, Jeffrey Wong wrote: >> >> Thanks for the clarification! >> >> I'll go ahead and use a template instead if that's what you're >> recommending. It makes the most sense to deprecate/undocument content if >> it's difficult to rectify strange differences with corner cases like that. >> >> Thanks! >> >> On Sunday, September 28, 2014 12:29:29 PM UTC-7, Michael DeHaan wrote: >>> >>> Those changes are related to some security fixes and various related >>> changes as a result of those fixes that came later, all aimed at preventing >>> unexpected argument insertion given untrusted data from remote hosts. >>> >>> So {{ foo }} is a request to insert something into a line, the way you >>> have it above, and then ansible converts that into module arguments. >>> >>> I have considered just undocumenting the "content" parameter -- we're >>> likely to do that -- as I think it leads to some confusing practices, >>> better served by "template" in most cases. >>> >>> One of those examples is pushing an embedded shell script inside a >>> playbook, when it could have been done in a one-liner with the "script" >>> module. >>> >>> If you think you can fix it and still keep the argument >>> detection/parsing in place, I'd be interested - but that's why it was >>> closed with the reasons given, and why I suggested how to avoid this. >>> >>> The long form is also needed to pass structured data to modules, as is >>> shown with the ec2 examples. >>> >>> >>> >>> >>> >>> >>> On Sat, Sep 27, 2014 at 1:08 PM, Jeffrey Wong <[email protected]> wrote: >>> >>>> Hi there! >>>> >>>> I noticed that ansible seemed to have done some updating with regards >>>> to multiline variables, and I'm a little confused about the way the >>>> variables are handled now. >>>> >>>> My use case comes from inserting private-key data into an encrypted >>>> yaml file via ansible-vault, and printing the contents via copy module's >>>> content directive. This worked great in 1.7.1, but with 1.7.2, it printed >>>> an extra newline between each line. Coincidentally, when I next deployed >>>> via ansible 1.7.2, my keys weren't working. >>>> >>>> The format is something like: >>>> >>>> group_vars/all.yml: >>>> key: |+ >>>> -----BEGIN PRIVATE KEY---- >>>> (private key) >>>> (private key) >>>> (private key) >>>> -----END PRIVATE KEY----- >>>> >>>> roles/tasks/main.yml: >>>> - copy: content="{{ key }}" dest="/etc/ssl/private/key" >>>> >>>> 1.7.1 (correct): >>>> -----BEGIN PRIVATE KEY---- >>>> (private key) >>>> (private key) >>>> (private key) >>>> -----END PRIVATE KEY----- >>>> >>>> 1.7.2 (incorrect): >>>> -----BEGIN PRIVATE KEY---- >>>> >>>> (private key) >>>> >>>> (private key) >>>> >>>> (private key) >>>> >>>> -----END PRIVATE KEY----- >>>> >>>> >>>> While looking through the github issues, there was a ticket that >>>> expressed exactly the issue I ran into: >>>> https://github.com/ansible/ansible/issues/9172 >>>> >>>> And it was resolved by following the 'long' format from: >>>> https://github.com/ansible/ansible/issues/9067 >>>> >>>> roles/tasks/main.yml (long format): >>>> - >>>> copy: >>>> content: "{{ key }}" >>>> dest: "/etc/ssl/private/key" >>>> >>>> >>>> However, these have since been closed as 'not a bug'. >>>> >>>> The way that multiline variables should not change no matter what >>>> format the user is using. I do not understand the difference between the >>>> two formats, why it should treat multiline variables differently, and how >>>> this is not a bug. Can someone shed some light on this issue? >>>> >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/ansible-project/2949f5ce-6f1b-40ec-bd79- >>>> 1f2b83357e42%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ansible-project/2949f5ce-6f1b-40ec-bd79-1f2b83357e42%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/8b37ad86-eafb-46da-a4d9-0ea4ed912b52%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/8b37ad86-eafb-46da-a4d9-0ea4ed912b52%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyaeOkoBRkNdPm_2Yv2XW7x-F%3DUpXNECiLputHRgwV6dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
