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.
For more options, visit https://groups.google.com/d/optout.
