Basically my question is (A) how is "broken" different from "working" in your two examples?
If I try to step back to the higher level, I think this may be saying something like "if role dependencies are used, look for files also in the paths the dependent role might be"? Though I'm having trouble fitting a use case to that one. (Also, role deps were never meant to be an inheritance mechanism, they are a dependency mechanism - run this before that). On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan <[email protected]> wrote: > 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%2BnsWgw8unMXDjBAMa4aSX-paid%3D6seh97LYnpJHXa322EDV_g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
