On 04/24/2014 09:53 PM, [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] <javascript:>> 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] >> <javascript:>. >> To post to this group, send email to >> [email protected] <javascript:>. >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/ansible-project/5357E3D3.5010408%40yahoo.gr >> >> <https://groups.google.com/d/msgid/ansible-project/5357E3D3.5010408%40yahoo.gr>. >> For more options, visit https://groups.google.com/d/optout >> <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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 >> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/07cea1c5-a6a3-436d-bf4b-296c356fdf67%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/07cea1c5-a6a3-436d-bf4b-296c356fdf67%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout.
Hi Ramon, What you suggest could be useful only if you just want to override some templates and/or files. But you may also want your 'extend' role to have some new tasks of its own, so that they are run after the invocation of the 'base' role. So that' s where the OO-like approach I suggest applies. You write a new role that can override relative paths when invoking the base role and which may also add new functionality with tasks of its own. It's not fully object oriented because you still cannot override tasks in a single pass (though this could be done with added syntax complexity), but you can have tasks in the 'extend' role that work to override changes made by tasks in the 'base' role. Above all, the approach I suggest is very simple and, by having an explicit option to enable this mode in the dependency statement, it's totally harmless and backwards-compatible. The above applies also to the suggestion of Strahinja to use the same role with a parameter that changes the template. It is bound to the functionality of a single role and does not allow for new (extended) functionality. Think that you may want to have multiple roles that each one extends the same base role, but has it's own set of overridden templates/files and new tasks. -- 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/535A083C.50303%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
