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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/535A4BFC.7040302%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
