Relative Search Paths

[Mike Ray]

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.

[Michael DeHaan]

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?

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Ray]

It might take me a few days yet, but I will try to create a minimalist one that shows what I am talking about.

[Mike Ray]

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:

[Michael DeHaan]

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:

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com.

[Michael DeHaan]

Gmail sent this email early, one sec while I finish it :)

[Michael DeHaan]

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).

[Mike Ray]

"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 :)