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]. 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. For more options, visit https://groups.google.com/d/optout.
