Why not use variables for what you want. If you would like to use different
templates for different servers using the same role, why not define a
default template file in defaults directory of the role something like this:
# foo_role/defaults/main.yml
---
foo_role_template_file: default.j2
and in the role tasks you just use:
# foo_role/tasks/main.yml
- template: src={{ foo_role_template_file }} dest=/etc/file.conf
Now if you would like to run this same role with a different template file,
just set a var:
foo_role_template_file: mytemplate.yml
in host_vars, or group_vars and copy the file into
foo_role/templates/mytemplate.yml.
On Thursday, April 24, 2014 8:53:42 PM UTC+2, [email protected] wrote:
>
> Hey Ernest0x,
>
> I don't think the dependencies currently stand to mean "extend" in the OO
> sense. All it means is "I depend on some othe role, so make sure that role
> is run before me". Each role is still an independent one. I believe this is
> a very clear and useful way of thinking of the dependecies of roles (i.e.
> create-some-nginx-configs-role depends on nginx-role - so nginx must be
> installed first).
>
> That being said, I have recognized the need for "overriding"
> files/templates in roles. I tested like this:
>
> global_roles_somewhere
> /galaxy_role_x
> /tasks
> /main.yml
> /templates
> /some_template.j2
>
> project_root
> /ansible
> /galaxy_role_x
> /templates
> /some_template.j2
> /playbook.yml
>
>
> In the playbook:
>
> roles:
> - galaxy_role_x
>
> -----
> This does not have the desired effect, as soon as you create the
> galaxy_role_x locally, it fails if it's not complete.
>
> ---> It should be possible that this role becomes a merged version of the
> "global" files + the "local" files, so my "local" some_template.j2
> overrides the "global" some_template.j2; but the role still has the
> "global" tasks/main.yml.
>
> This accomplishes what you are suggesting, right?
> (I have no idea if the Ansible project want's this kind of added
> complexity, nor if it's worth the trouble to build)
>
>
> Regards,
>
>
> Ramon
>
>
> On Thursday, April 24, 2014 5:17:37 PM UTC+2, Ernest0x wrote:
>>
>> On 04/24/14 15:50, Michael DeHaan wrote:
>>
>> "I have not done any tests yet, but what is currently the expected
>> behavior when a role that depends on a common role provides a template
>> with the same name as the common role? "
>>
>> I'm having a hard time parsing this. It might be helpful to see a
>> playbook example so we could see the ansible source.
>>
>> In many cases, trying things is usually easiest :)
>>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 12:01 PM, Petros Moisiadis <[email protected]>wrote:
>>
>>> Hello,
>>>
>>> I have not done any tests yet, but what is currently the expected
>>> behavior when a role that depends on a common role provides a template
>>> with the same name as the common role? Is the task in the common role
>>> (being invoked by the dependent role) executed with the template
>>> provided by the common role or does the template provided by the
>>> dependent role override the template in the common role?
>>>
>>> --
>>> 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/5357E3D3.5010408%40yahoo.gr
>>> .
>>> 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%2BnsWgwxLivV9WAj99%2BH7E%3DsAv2ZTt3FrpRJ8H4f3m4fGKCWiQ%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwxLivV9WAj99%2BH7E%3DsAv2ZTt3FrpRJ8H4f3m4fGKCWiQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> Well, I did some tests and figured out how things work myself. :)
>> Nevertheless, I will try to describe it better and also go further to
>> suggest a new feature relevant to this discussion.
>>
>> So, consider the following directory structure:
>>
>> root_directory
>> myplaybook.yml
>> roles
>> base
>> tasks
>> main.yml
>> templates
>> mytemplate.j2
>> extended
>> tasks
>> main.yml
>> templates
>> mytemplate.j2
>> meta
>> main.yml
>>
>>
>> roles/extended/meta/main.yml contains:
>> ---
>> dependencies:
>> - { role: base }
>>
>>
>> And myplaybook.yml contains:
>> ---
>> - hosts: localhost
>> roles:
>> - extended
>>
>>
>> There are two roles: the 'base' role and the 'extended' role. Assume that
>> the 'base' role has a task that runs a template action with
>> src=mytemplate.j2 (relative path). The 'extended' role provides a
>> template with the same filename 'mytemplate.j2' but different content. To
>> make things look simpler let's assume that the 'extended' role has no tasks
>> at all, so it only calls the 'base' role. Now that I have tested it myself,
>> I can tell that the current behavior when the 'base' role is being invoked
>> by the 'extended' role is to run the 'base' role's template task using the
>> 'roles/base/templates/mytemplate.j2' file, not the
>> 'roles/extended/templates/mytemplate.j2' file provided by the 'extended'
>> role. The 'extended' role is only calling the 'base' role as it is. It does
>> not override the template and file paths. In other words, file and template
>> relative paths are resolved to paths relative to the 'base' role, not to
>> paths relative to 'extended' role. There is no 'overriding' behavior. So, I
>> am thinking that making this "overriding" behavior possible would be really
>> a useful feature, which would allow to write specialized roles that provide
>> more specific templates/files to be used with tasks defined in more generic
>> (base) roles. This behavior would come very handy, for example, if you see
>> a nice role on Galaxy, but would need some changes in a couple of templates
>> to adapt it to your needs. You would prefer not to copy the whole role
>> because you would like to avoid to do the copy each time the "upstream"
>> role is upgraded. Writing a dependent role that provides just the templates
>> that need to be overridden would be much cleaner.
>>
>> The above behavior could be enabled with an 'override_relative_paths:
>> yes' meta attribute in the dependency statement. For example, to enable
>> this in the example above, the roles/extended/meta/main.yml file above
>> would be written like this:
>> ---
>> dependencies:
>> - { role: base, override_relative_paths: yes }
>>
>>
>> What do you think?
>>
>
--
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/35c9e108-076e-4b0b-b275-ecd33d7d22e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
