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 <mich...@ansible.com
> <mailto:mich...@ansible.com>> 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 <ansible-project@googlegroups.com
>     <mailto:ansible-project@googlegroups.com>> 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 <ansible-project@googlegroups.com
>>         <mailto:ansible-project@googlegroups.com>> 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
>>             ansible-project+unsubscr...@googlegroups.com
>>             <mailto:ansible-project%2bunsubscr...@googlegroups.com>.
>>             To post to this group, send email to
>>             ansible-project@googlegroups.com
>>             <mailto:ansible-project@googlegroups.com>.
>>             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
>>         ansible-project+unsubscr...@googlegroups.com
>>         <mailto:ansible-project+unsubscr...@googlegroups.com>.
>>         To post to this group, send email to
>>         ansible-project@googlegroups.com
>>         <mailto:ansible-project@googlegroups.com>.
>>         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
>         ansible-project+unsubscr...@googlegroups.com
>         <mailto:ansible-project+unsubscr...@googlegroups.com>.
>         To post to this group, send email to
>         ansible-project@googlegroups.com
>         <mailto:ansible-project@googlegroups.com>.
>         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 ansible-project+unsubscr...@googlegroups.com
>     <mailto:ansible-project+unsubscr...@googlegroups.com>.
>     To post to this group, send email to
>     ansible-project@googlegroups.com
>     <mailto:ansible-project@googlegroups.com>.
>     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 ansible-project+unsubscr...@googlegroups.com
> <mailto:ansible-project+unsubscr...@googlegroups.com>.
> To post to this group, send email to ansible-project@googlegroups.com
> <mailto:ansible-project@googlegroups.com>.
> 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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/5385E149.8010804%40yahoo.gr.
For more options, visit https://groups.google.com/d/optout.

Reply via email to