On 04/25/14 17:09, Strahinja Kustudić wrote: > 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 > You are assuming things here that they are not correct. 1. As I said before lineinfile does not help because it has not the power of a template engine and cannot handle (easily) more complex scenarios. 2. The common role works for ~90% of the hosts. So, it's quite common.
Also, one should think of the general need for a mode like the one I suggest. Perhaps, my example is not the best. Actually, I could "attack" my example myself and say "don't use /etc/hosts, use DNS". However, the point of my example was not to find the best solution for me, but to understand what I suggest and see how useful such a feature could be in general. > > 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] > <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/74b560fb-d750-4e8b-8e38-065ff4f42051%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/74b560fb-d750-4e8b-8e38-065ff4f42051%40googlegroups.com?utm_medium=email&utm_source=footer>. > 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/535A73B5.4080907%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
