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 <a...@frontrowed.com>
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 <awo...@gmail.com> 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 ansible-proje...@googlegroups.com.
>>>> To post to this group, send email to ansible...@googlegroups.com.
>>>> 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 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/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 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/CA%2BnsWgyaeOkoBRkNdPm_2Yv2XW7x-F%3DUpXNECiLputHRgwV6dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
