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%2BnsWgzJRLW%3DsSdfhY169UEhuCLXkWtSZDp%3D5i4kbyTWS3kZ%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to