Use case 2 could be handled like that, but I feel that is just a work-around for a missing feature in ansible. Those two tasks actually is one single task that needed to be split into two parts because templates cannot receive a set of facts to use.
In fact I was tempted to work around the whole thing by creating a task file that included ONLY that one template creation task, and included passed the necessary variables to that, which is obviously a hack, and also does not work with with_items, or with_dict - include: create_template.yml foo=bar, baz=raz Regards, Akos Vandra On 5 September 2014 03:23, Michael DeHaan <[email protected]> wrote: > 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. -- 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/CAHHcNocmQn%2BPMaVGd0U9-q9dJ-JCi8%2BLusgEZV-54_TCviX-TQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
