Thanks, I understand #1. Use case #2 could be handled by:
- set_fact: mode='serverAuth' - template: ... - set_fact: mode='clientAuth' - template: ... Though I'd be tempted to use seperate templates and keep it simple. On Thu, Sep 4, 2014 at 5:26 AM, Akos Vandra <[email protected]> wrote: > A plus for Use Case 1: > > Adding fixed ip addresses like this: > > - template: template: src=foo.j2, dest=/etc/hosts.d/localhost > dns=localhost ip=127.0.0.1 > > On 4 September 2014 11:20, Akos Vandra <[email protected]> wrote: > > 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/CAHHcNodPjW8ziMOPgPT1%3Di7DUe-vwHQRoa-%3D_ytaAXDNcrOZCw%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%2BnsWgzGvybikjKSZWMKShvxHvRQxS07b55EiwdW8gpzR_mn4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
