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.
