"Broken" and "working" are exactly the same except that the certificate that "working" uses is within the apache2-ssl directory structure (i.e. roles/apache2/files/external.crt) whereas "broken" has its own certificate in its own directory structure (i.e. roles/servers/broken/files/IN_MY_DIRECTORY.crt) . This is the only difference in this example.
While technically I did not setup role dependencies (according to documentation http://docs.ansible.com/playbooks_roles.html#role-dependencies), that is in an essence how I am using the apache-ssl playbook in this example. And I believe you have accurately stated what I attempted to by taking a step back, let me restate it and make sure we understand each other: "for each role (r) that is listed as a dependency of some other role (x), when running that role (r), prioritize files provided by role (x)". The use cases are for when a file would have to be so different from the generic template that it could not be easily mangled or assembled using current modules or that each instance of that file is unique such that no template exists. So in my example, "external.crt" and "IN_MY_DIRECTORY.crt" are two completely different SSL certificates. They have no relation to each other (except that they are SSL certificates), and no relation to the generic apache-ssl playbook because they are server specific certificates. Yes, I do agree that it is odd for a dependency to "inherit" the dependent's directory structure. As I mentioned in the readme, there are sufficiently valid ways to cope with this problem, so if this is too odd, pointless or "un-Ansible-like", it won't stop my setup :) On Monday, August 4, 2014 3:16:24 PM UTC-5, Michael DeHaan wrote: > > 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] > <javascript:>> 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] >> <javascript:>> 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] >>> <javascript:>> 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] <javascript:>. >>>> To post to this group, send email to [email protected] >>>> <javascript:>. >>>> 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/eec47dab-69e1-4e07-876c-5983b5fcfe6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
