Gmail sent this email early, one sec while I finish it :)
On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan <[email protected]> wrote: > You lost me on sentence #2 about inheritance, as I'm unclear how > inheritance applies to directories. > > "It would be nice if one role could inherit another's directory > structure." > > Looking at the two YAML files, I see both "broken" and "working" contain > the same playbook basically: > > > > > On Mon, Aug 4, 2014 at 2:01 PM, Mike Ray <[email protected]> > wrote: > >> Please make sure you check out the README as I believe I not only better >> explain the "problem" but note ways I could make it work with the existing >> Ansible (things I hadn't realized when I made this request). >> >> Basically, this is a pretty specific request to slightly expand >> functionality and is probably not worth the time-investment. >> >> But, since I promised it, here is a github where you can see a skinned >> down example: >> https://github.com/rayvenshire/Ansible/tree/master/relative_search_paths_3j0SYZN4r3Q >> >> On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote: >> >>> I'm having trouble parsing this one, sorry. >>> >>> Would it be possible to see a git repo or something for this ticket that >>> minimally reproduces the question? >>> >>> >>> On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray <[email protected]> wrote: >>> >>>> As of 1.6.2 (yes, not quite current, though I did not see anything in >>>> the changelog that addressed this), when using roles, each role is called >>>> relative to its own directory. >>>> >>>> E.g. >>>> >>>> playbook1.yml : >>>> --- >>>> - hosts: '{{ hostlist }}' >>>> remote_user: root >>>> roles: >>>> - role: apache2 >>>> - role: mysql >>>> >>>> >>>> Both apache2 and mysql roles will be called against the hosts defined >>>> by the host var 'hostlist'. This is all well and good; however, in our >>>> current setup, we have roles for generic functionality (e.g. apache, mysql, >>>> etc) and also server specific playbooks. These server specific playbooks >>>> have a few one-off tasks that do not apply to other roles. One of these >>>> might look like: >>>> >>>> server1.yml : >>>> --- >>>> - hosts: '{{ hostlist }}' >>>> remote_user: root >>>> roles: >>>> - role: apache2 >>>> - role: servers/myserver >>>> >>>> Currently with our apache playbook, we allow for overloading a variable >>>> in the top-level playbook to change with SSL certificate is used. >>>> >>>> server1.yml : >>>> --- >>>> - hosts: '{{ hostlist }}' >>>> remote_user: root >>>> roles: >>>> - role: apache2 >>>> - role: servers/myserver >>>> >>>> vars: >>>> - certificate: "not_default_cert.crt" >>>> >>>> However, this means when the apache2 playbook runs it will expand {{ >>>> certificate }} to "not_default_cert.crt" and the only way it would work is >>>> if that certificate exists in the apache2 folder directory (e.g. >>>> roles/apache2/files/not_default_cert.crt). >>>> >>>> If there is only one such file, it won't ever be too bad, but if many >>>> servers needed to overload that file, we'd end up with many "extra" files >>>> in that directory that really don't apply to that role. It would be nicer >>>> if those files could reside in their own server specific directory (e.g. >>>> roles/servers/myserver/files/not_default_cert.crt). That way the >>>> "base" role would only have the absolutely necessary files and all specific >>>> files could reside within the server's playbook to which they belonged. >>>> >>>> To my understanding there is no such "search for files here and also >>>> here" directive, nor any sort of inheritance that currently accomplishes >>>> this. >>>> >>>> As stated before, I am running 1.6.2, so if this functionality is >>>> implemented, I apologize, and I will upgrade when I have the chance. >>>> >>>> If others have come across this problem and have a different >>>> organizational implementation that avoids this issue, I'd love to hear it. >>>> >>>> -- >>>> 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/62e923b1-f78a-4fc8-98a3- >>>> b5b2cebe8d81%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%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 [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/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com >> <https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%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 [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%2BnsWgwCb89wv3Yqiy_FpSUd722tXu%3Doh_WDHKF1EasY5D%2BA9Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
