"That means when a role is being deployed because of a role dependency, its template tasks could use blocks possibly provided by any role that depends on it and is included in the active dependency chain."
The problem is 95% of our users including myself have trouble with this wording :) We avoid things we can't explain, and that would confuse everyone when they read it. It's worked pretty well as a guideline in making every language decision in this project so far :) I would still maintain that there are some (usually mostly coming from Chef) that try to solve too many problems with role dependencies. They were added to end a certain class of repeated question, but in general, they are overused and mostly *not* needed. Role dependences are not an inheritance mechanism, they are a "run these roles before these roles" mechanism. On Wed, May 28, 2014 at 4:20 AM, 'Petros Moisiadis' via Ansible Project < [email protected]> wrote: > On 05/27/2014 11:04 PM, Michael DeHaan wrote: > > "But we could make role dependencies allow for template overrides / > injections" > > I find this kind of language hard to understand. > > ", I can see great potential if we make role > dependencies smart enough to allow template inheritance between > dependent roles. " > > I don't even know what this means. > > Ansible isn't a programing language, I would find this easier if we did > not try to use the phrase "inheritance" where it didn't make sense. > > Did you mean including a template in another template? > > > The phrase "template inheritance" is what is officially used in the jinja2 > docs (http://jinja.pocoo.org/docs/templates/#template-inheritance). I am > copying from jinja2 docs: > "Template inheritance allows you to build a base “skeleton” template that > contains all the common elements of your site and defines blocks that child > templates can override." > > So, what I am suggesting is adding a new possibility on top of role > dependencies, which would allow to write a template in a dependent role > that extends a template of a role it depends to. In other words, a role > would be allowed to have child templates that provide content for blocks > defined in a 'skeleton' template of a role it depends to. That means when a > role is being deployed because of a role dependency, its template tasks > could use blocks possibly provided by any role that depends on it and is > included in the active dependency chain. I have already given an example of > a 'wsgi_app' role that depends on an 'apache_role'. The 'apache_role' would > provide a template with all common things as well as an "extra" block, > which could be overridden by the "wsgi_app" role in order to provide > wsgi-specific functionality to the apache configuration. > > All this allows for a really modular design of roles. An 'apache' role > with a good skeleton template would allow to have a great variety of > dependent roles such as 'fastcgi_app', 'wsgi_app', 'django_app', > 'ruby_on_rails_app', etc., without having to repeat common functionality on > each role and avoiding the creation of a huge 'apache' role that would try > to do everything driven by a great amount of parameters for choosing the > appropriate templates and a spaghetti of conditional includes. > > Ansible is not a programming language, but it already contains a powerful > template language. Why not take full advantage of it for the benefit of a > better role design? > > > > > > On Tue, May 27, 2014 at 1:58 PM, 'Petros Moisiadis' via Ansible Project < > [email protected]> wrote: > >> On 05/27/14 20:26, Michael DeHaan wrote: >> > Really, role deps shouldn't be looked at like inheritance though - >> > they are simply NOT inheritance. They are things to do *first*. >> > >> > It might be better to pass a parameter into the role instead (like you >> > have) with what filename to use, I'm unclear as to why you think it >> > needs an absolute path though. >> >> >> But we could make role dependencies allow for template overrides / >> injections. Judging by discussions in several related topics, it seems >> that this would be a feature that people would want to have, so I do not >> understand why you are against some little level of inheritance for the >> templates. In fact, I can see great potential if we make role >> dependencies smart enough to allow template inheritance between >> dependent roles. Jinja already has this power built-in. Why don't we >> take advantage of it? Imagine an 'apache' role that provides a vhost >> template with a "{% block extra %}{% endblock %}" jinja block and a >> 'wsgi_app' role which depends on 'apache' role and provides content for >> that 'extra' block. That would allow for a really modular design of >> roles, instead of having to maintain huge, monolithic roles that do >> everything with a lot of conditional includes and passing "strange" role >> parameters. Role parameters are exactly what you want for things such as >> 'http_port' or 'bind_address', but using them for practically choosing a >> "more specific role for the role" is far from elegant design. >> >> -- >> 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/5384D232.9000106%40yahoo.gr >> . >> 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/CA%2BnsWgwKB6HCf%2Bj_6P4X2h8ZYcgc6dyT45fj8%3DYvfH90bOM2kw%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwKB6HCf%2Bj_6P4X2h8ZYcgc6dyT45fj8%3DYvfH90bOM2kw%40mail.gmail.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/53859C4F.8070205%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/53859C4F.8070205%40yahoo.gr?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/CA%2BnsWgxo04S-s8qdo_aOBeBmQJT8h4oTT-sBue-c7ecAi14N0g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
