Ok so it's still not "inheritance" (this is an uneducated misuse of the term by Jinja, it's encapsulation, quite a different concept), ansible roles themselves are definitely not inheritance.
(I've also written a lot in Django) Ultimately the problem is we have an irresolveable communication gap about how you are describing your technical idea. It seems to me you are saying when a template includes another template it should also look in the "template/" directories that belong to the dependent roles, so it can find things there, but this should only apply when a template includes another template. Ultimately, I don't think this applies well to Ansible. Ansible looks at role dependencies just like package managers look at package dependencies. They are things that need to be applied first, but there is no concept of search paths or inheritance/encapsulation applied. On Wed, May 28, 2014 at 9:14 AM, 'Petros Moisiadis' via Ansible Project < [email protected]> wrote: > On 05/28/14 15:13, James Cammarata wrote: > > Absolutely. Role dependencies are more like package dependencies - if > package A depends on package B, it means you need to install package B > first. > > In no circumstances should package B include files that package A is > going to overwrite. It would make things extremely confusing and impossible > to implement, especially when you start talking about multiple levels of > dependencies, and what should happen if there are multiple dependencies > (package B and C require package A, but both override a file in A, who > wins?). > > > I don't think your concerns are valid. The last role in the dependency > chain should always win. This is how it already works in systems where > template inheritance can be applied (e.g. Django). Also, I propose an > _explicit_ directive to enable template inheritance in a role dependency > statement (turned off by default), so people will always know what is going > on. > > > > > > On Wed, May 28, 2014 at 7:04 AM, Michael DeHaan <[email protected]>wrote: > >> "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<https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxo04S-s8qdo_aOBeBmQJT8h4oTT-sBue-c7ecAi14N0g%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/CAMFyvFhOo_vsgRpbfg%3DuBJ_hhbeQ_Tnw0H9RZ%3Dp_OZvw_F%3DsPA%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAMFyvFhOo_vsgRpbfg%3DuBJ_hhbeQ_Tnw0H9RZ%3Dp_OZvw_F%3DsPA%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/5385E149.8010804%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/5385E149.8010804%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%2BnsWgzGpgMENkBgxG96C1CLR34AsMyZR%3D6J93EibXao-8gjtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
