Hi!
Sorry for not copying hyperlinks, I hate that too - I guess I just got
too confortable with github doing that for me :)
I have written down a few use cases in my previous emails and the
ticket, but I will summarize them here again for simplicity's sake.
I have also just encountered another usecase, i'm detailing it as the first one.
The problem with the current setup is that by not being able to pass
in, rename, or specify how to look up input variables, it hinders
template reusability.
*** USE CASE 1 ***
I have a list of hosts, and for reasons outside the scope of this
discussion, I need to create a /etc/hosts.d directory containing one
entry per file, which will be concatenated into one /etc/hosts file by
an incron job.
So I'd like to do this:
- template: src=foo.j2, dest=/etc/hosts.d/{{item}}
dns={{hostvars[item].ansible_hostname}}.vpn
ip={{hostvars[item].ansible_tun0.ipv4.address}}
with_items: {{ groups["vpn-clients"] }}
And yes, I could use that complicated lookup within the template, but
would be mixing up layers. The tasks should know how to find out what
to render, and templates should be dead simple, just render what is
given to them.
And I couldn't reuse this template if I'd hardcode the way to look up
the tunnel0 interface address into them in case I would need (and I
do) to
add other interface addresses to the list, like so:
- template: src=foo.j2, dest=/etc/hosts.d/{{item}}
dns={{hostvars[item].ansible_hostname}}.public
ip={{hostvars[item].ansible_eth0.ipv4.address}}
with_items: {{ groups["all"] }}
**** USE CASE 2 ****
Due to openSSL not being able to accept extendedusagetypes from the
command line, only from config files, I need to generate a temporary
configuration file, so I would need to do something similar to this:
- template: src=openssl_config.j2 dest=/tmp/openssl.cnf usage=serverAuth
- name: sign client csrs
shell: openssl req -in {{item}} -config /tmp/openssl.cnf..... [sign items]
with_items: server_certs
- template: src=openssl_config.j2 dest=/tmp/openssl.cnf usage=clientAuth
- name: sign server csrs
shell: openssl req -in {{item}} -config /tmp/openssl.cnf .....
with_items: client_certs
**** USE CASE 3 ****
Very similar to Use case 1, it was mentioned by @ iraksdale in the
first Issue on Gtihub:
Have to agree with @claco here. I'm using a template to output
multiple files based on a with_dict loop, and semantically it kind of
sucks to use item.key or item.value all over the template - doesn't
make them very reusable.
It would be nice to define "service_name" or "hostname" variables or
whatever in the playbook where it's easy to see their relationship to
the variable being looped, and have the templates use {{service_name}}
instead of having to put "whatever_{{item.key}}" in the templates.
Regards,
Akos Vandra
On 3 September 2014 00:52, Michael DeHaan <[email protected]> wrote:
> Small request - when referencing tickets, hyperlinks keep me from copying
> and pasting every link and then clicking on them, and several thousand other
> people from doing the same :) ... I looked them up and summarized here.
>
> The first ticket, which we declined as a feature early in our development.
> Not an issue per say but more of a feature request:
> https://github.com/ansible/ansible/issues/4546. The ticket on
> https://github.com/ansible/ansible/issues/8733 is a duplicate of 4546.
>
> Basically I'd like to explore what your particular use case is, so that we
> can find an idiomatic solution in Ansible, if one exists.
>
> Can we explore what you are modeling? I'm wanting to make sure this
> shouldn't be a role, and so on, or that it can't be done more natively in
> other ways.
>
> I'm not opposed to the feature, but I'm also wanting to limit having 7000
> different ways to set variables and pass them around, and in many cases this
> would be abused by folks doing "x={{x}}" and not knowing that all the
> variables are automatically passed down.
>
> It may be that your particular use case does warrant this, but I would like
> to understand it if possible.
>
> Thanks!
>
>
>
>
> On Sun, Aug 31, 2014 at 11:16 AM, Akos Vandra <[email protected]> wrote:
>>
>> Hello everyone!
>>
>> I was asked to bring this up in the email list as well. Please see
>> issues #8733 and #4546 for the origins of this email.
>>
>> Just encountered the problem reported in #4546
>> Due to openSSL not being able to accept extendedusagetypes from the
>> command line, only from config files, I need to generate a temporary
>> configuration file, so I would need to do something similar to this:
>>
>> - template: src=openssl_config.j2 dest=/tmp/openssl.cnf
>> vars:
>> usage: serverAuth
>> - name: sign client csrs
>> shell: openssl req -in {{item}} -config /tmp/openssl.cnf..... [sign
>> items]
>> with_items: server_certs
>>
>> - template: src=openssl_config.j2 dest=/tmp/openssl.cnf
>> vars:
>> usage: clientAuth
>> - name: sign server csrs
>> shell: openssl req -in {{item}} -config /tmp/openssl.cnf .....
>> with_items: client_certs
>>
>> Without being able to manipulate the usage variable passed to the
>> template, one can not reuse the config template.
>>
>> Of course this could be worked around by putting the two tasks into a
>> different file, and then including it with parameters (which is
>> supported btw), but it seems silly that one needs to do that if one
>> wants to reuse the template.
>>
>> I'd like to see the ability to pass in extra variables not implemented
>> in the template module, but globally, so that one could include extra
>> variables to *any* module, just like the when, or changed_when, etc.
>> work.
>>
>> Regards,
>> Akos Vandra
>>
>> There was another comment to about 3 weeks ago from @iraksdale
>>
>> ""
>> Have to agree with @claco here. I'm using a template to output
>> multiple files based on a with_dict loop, and semantically it kind of
>> sucks to use item.key or item.value all over the template - doesn't
>> make them very reusable.
>>
>> It would be nice to define "service_name" or "hostname" variables or
>> whatever in the playbook where it's easy to see their relationship to
>> the variable being looped, and have the templates use {{service_name}}
>> instead of having to put "whatever_{{item.key}}" in the templates.
>>
>> It really hinders the reuse of templates, because it marries them to a
>> particular playbook structure, and the passthrough to the file module
>> could be preserved if you just added a template_vars argument that
>> would make its contents available to the template.
>>
>> As a new user to ansible, I'd say the lack of this is really
>> counterintuitive. Is it possible to reconsider this decision? I think
>> it adds a lot to the reusability & understandability of templates.
>> ""
>>
>> Regards,
>> Akos Vandra
>>
>> --
>> 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/CAHHcNodbcGNKdrCzwv_4juKvBEq2nmXP_nD%2B3DksGPra3eh-gw%40mail.gmail.com.
>> 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%2BnsWgy5yFATNdYS2Xa-neoi3hV7TDjFQRBAPjodNTxMP1VEQQ%40mail.gmail.com.
> 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/CAHHcNocQM_DK-mRHnKnWg4Ue1d%3DdUaMUhS_gncNJBw2J9Q3KNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
