I'm not at all saying that the role HAS to know about the template path, 
I'm saying that during the passing of the parameters of that role you could 
pass in a string that represents a file and that file could either exist in 
the role that has the dependency declaration or the role that you're 
calling. It's a simple change to the template path when you're calling 
roles within the dependency list. It could allow you to override templates 
that are present in the dependant roles without having to copy out, or 
change a potentially third party role. This also has the benefit in that 
you don't change templates or files within roles, and can potentially 
update them if they're from a third party without causing any conflicts or 
storing your own template files within that role.

To me it seems the role should be responsible for it's own configuration 
files and setting their parameters rather than dropping files into 
directories and calling handlers externally, but perhaps that's just my 
perception coming from other systems?

On Thursday, 29 May 2014 17:20:48 UTC+1, Adam Morris wrote:
>
>
>
> On Thursday, May 29, 2014 1:52:16 AM UTC-7, Paul Oyston wrote:
>>
>> Just to confirm, I wasn't suggesting any form of inheritance in any 
>> way,...
>>
>  
>  I understand what you are saying, but unless the role that you run first 
> (avoiding the d word) knows to expect a template from the later role then 
> you have an issue.  If all roles were written to add fragments and assemble 
> configuration files then they could work together (or for applications that 
> have configuration directories that's already solved for you).  But then 
> you are either going to have to go in and retrofit all existing roles or 
> only work with a subset.  There is no enforced coding standard for roles so 
> I think that we are going to have to live with the current situation.  
>
> If you write your roles to be accepting of fragments then that's the best 
> that you can do...
>
> Adam
>

-- 
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/4b452627-8c2a-4f8c-813e-8eec49ccd58c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to