You are complicating things with all this, think of it a lot simpler. Regarding your example you can solve #1 in two ways:
1. Don't set hosts file with a template, but using lineinfile 2. Don't change the hosts file in common role, since from the looks of it, it is not "common" enough On Friday, April 25, 2014 1:50:20 PM UTC+2, Ernest0x wrote: > > On 04/25/14 13:28, Ramon de la Fuente wrote: > > Hi, > > > > I understand the suggestion about adding more variables to your > templates to be able to steer with variables; and I understand defaults - > this is exactly how we try to build roles for galaxy. The problem lies with > roles beyond your own control - i.e. roles by other people where you want > to make a change in the template that was not made possible with variables > (a pull-request on that role might also do the trick). > The problem does not lie with roles beyond your own control only. You > may also have created and fully control a 'base' role with templates > that work for most cases, but you also have some special cases that > cannot be handled with these "base" templates. So you must provide > special templates that override these templates. One would say that > Strahinja's suggestion of passing the templates that need to be changed > as parameters to the role would be enough. The problem with that > approach has to do with the place where these "special" templates should > be kept and maintained. Since they are used to provide special, > non-basic content, they do not belong to the 'base' role. Instead they > should be part of another "special" role that depends on the "base" role > and provides special templates to make tasks in the "base" role render > the templates the way the "special" role wants. > > I will give an example: > > Let's say you have a "common" role that creates "/etc/hosts" from a > template which adds a line for the primary interface. Then, you also > have a 'cluster_node' role that needs some extra lines in "/etc/hosts" > for inter-cluster communication with hostnames. You cannot use a task > that modifies (e.g. with lineinfile) "/etc/hosts" after it having been > created by the "common" role, because the extra lines you want to add > can only be created with template logic. So you have two options here: > > 1) Create the special template and also create a copy of the same task > along with any accompanying tasks and handlers in the "cluster_node" > role tasks to re-render the file. This is unneeded and possibly > interruptive duplication of a task that should be run only once. Ugly. > > 2) Just create the special template and tell "common" role in the > dependency statement to first try to resolve its relative paths to the > paths that "cluster_node" provides. This is clean, without double > execution of a task which should be run only once. > > > > I think I would draw the line at overriding files/templates though. Or > perhaps a whole task lists. If you want to add tasks to a role - i'd > suggest adding a separate role to the playlist following the previous role > you wanted to adjust - or adding pre_tasks/post_tasks to your playbook. > Extending tasks sounds like a bridge too far... > I agree. That' why I suggest an option only for overriding > templates/files. > > > for me, Ansible works because of it's simplicity, and I "extending" > roles would hurt that. BC-Break or not, it adds complexity to maintain. > > My 2cts. > > > > -- 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/74b560fb-d750-4e8b-8e38-065ff4f42051%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
