On 04/25/14 17:48, Strahinja Kustudić wrote: > I can see your suggestion being useful, but for now, you just have to > think of roles as group of similar tasks and that is all, don't think > of them as classes in an OO language. I don't see that this will > change any time soon. >
Actually, from users' point, I think that it is not a big deal to make this possible. My suggestion does not involve rethinking about roles, as it does not bring any change in the current behavior that users need to learn about (if they don't want to) and adapt their ansible stuff to. What I suggest is an explicit, simple syntax addition that would enable an OO-like behavior only for those who need it and only for the cases it is actually needed. Users don't need to change their minds and try thinking of roles like classes in OOP, if they don't want that functionality. Besides, even if they want that functionality, they don't have to understand anything about classes and OOP, as the only understanding needed in this case is about templates/files that can be overridden. The "OO-like" wording is somewhat misleading, because it would be familiar only to those who already know about the OO paradigm. > On Friday, April 25, 2014 4:39:49 PM UTC+2, Ernest0x wrote: > > 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 ansible-proje...@googlegroups.com <javascript:>. >> To post to this group, send email to ansible...@googlegroups.com >> <javascript:>. >> 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 >> <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 ansible-project+unsubscr...@googlegroups.com > <mailto:ansible-project+unsubscr...@googlegroups.com>. > To post to this group, send email to ansible-project@googlegroups.com > <mailto:ansible-project@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/07350b96-35b5-4d11-8d1e-979cc435dd1c%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/07350b96-35b5-4d11-8d1e-979cc435dd1c%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 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/535A9424.4080908%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
