On 05/28/14 15:04, Michael DeHaan 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. > >
I am not sure if that "95%" is valid... I don't think that template inheritance is rocket science. Thousands of users (e.g. including people in the great community of Django, which has a template language very similar to jinja2) are already using it for better design and reusability. Please, think of this workflow: - You define an empty block called 'extra' in a template file named "mytemplate.j2" belonging to role A. - You write a role B that depends on role A. In the dependency statement you state that: a) Role B depends on role A b) Templates of role A can be overridden by templates provided by role B. - You define a block named "extra" in a template file also named "mytemplate.j2", but belonging to role B. Obviously, you put in that block content that is specific for role B. - When role B is applied, it first calls role A. - Role A, when it is called by role B, renders "mytemplate.j2" with the "extra" block overridden with content provided by role B's "mytemplate.j2". Do you really think that the above is something that normal users could not understand? > > On Wed, May 28, 2014 at 4:20 AM, 'Petros Moisiadis' via Ansible > Project <[email protected] > <mailto:[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] >> <mailto:[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] >> <mailto:ansible-project%[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/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] >> <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/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] > <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/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] > <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/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/5385DF58.5090605%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
