Hi All, The "inheritance" discussion keeps popping up, appearantly there's value in there somewhere.. I'd like to add my 2ct, but just with regards to using galaxy roles.
First: it's obviously not "inheritance", I'd like to say "override" (like variables override eachother according to precedence), and limit the scope only to files/templates. The case is, I can find a prefect role in Galaxy, with one single problem: I'd like to use my own template instead of the included template. Currently, I cannot use the role, I must duplicate the entire thing and replace the template. It would be nice if there was a way to use my own template, in place of the role's template. The point has been made that this is already possible with a variable for the template name, but this would require other people to change their roles [which is absolutely an option, considering they're open source]. The way I would expect it to work is just adding the files in a roles_path that has precedence... It was outlined here in more detail: https://groups.google.com/d/msg/ansible-project/9xRyYIOdSro/aGF5L7F03PoJ But kind of got buried in talk of multiple reversed depedency inheritance injection encaptulation. Kind regards, Ramon On Wednesday, May 28, 2014 3:21:09 PM UTC+2, Michael DeHaan wrote: > > 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] <javascript:>> 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]<javascript:> >> > 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] <javascript:>> 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] <javascript:>> 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] <javascript:>. >>>>> To post to this group, send email to >>>>> [email protected]<javascript:> >>>>> . >>>>> 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] <javascript:>. >>>> To post to this group, send email to >>>> [email protected]<javascript:> >>>> . >>>> 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] <javascript:>. >>>> To post to this group, send email to >>>> [email protected]<javascript:> >>>> . >>>> 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] <javascript:>. >>> To post to this group, send email to >>> [email protected]<javascript:> >>> . >>> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> 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/0c7bb1fc-7835-488f-81db-8ba44a974ff1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
