FAQ
As of 1.6.2 (yes, not quite current, though I did not see anything in the
changelog that addressed this), when using roles, each role is called
relative to its own directory.

E.g.

playbook1.yml :
---
  - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
     - role: apache2
     - role: mysql


Both apache2 and mysql roles will be called against the hosts defined by
the host var 'hostlist'. This is all well and good; however, in our current
setup, we have roles for generic functionality (e.g. apache, mysql, etc)
and also server specific playbooks. These server specific playbooks have a
few one-off tasks that do not apply to other roles. One of these might look
like:

server1.yml :
---
  - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
      - role: apache2
      - role: servers/myserver

Currently with our apache playbook, we allow for overloading a variable in
the top-level playbook to change with SSL certificate is used.

server1.yml :
---
  - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
      - role: apache2
      - role: servers/myserver

    vars:
      - certificate: "not_default_cert.crt"

However, this means when the apache2 playbook runs it will expand {{
certificate }} to "not_default_cert.crt" and the only way it would work is
if that certificate exists in the apache2 folder directory (e.g.
roles/apache2/files/not_default_cert.crt).

If there is only one such file, it won't ever be too bad, but if many
servers needed to overload that file, we'd end up with many "extra" files
in that directory that really don't apply to that role. It would be nicer
if those files could reside in their own server specific directory (e.g.
roles/servers/myserver/files/not_default_cert.crt). That way the "base"
role would only have the absolutely necessary files and all specific files
could reside within the server's playbook to which they belonged.

To my understanding there is no such "search for files here and also here"
directive, nor any sort of inheritance that currently accomplishes this.

As stated before, I am running 1.6.2, so if this functionality is
implemented, I apologize, and I will upgrade when I have the chance.

If others have come across this problem and have a different organizational
implementation that avoids this issue, I'd love to hear it.

--
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+unsubscribe@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/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Michael DeHaan at Jul 29, 2014 at 9:04 pm
    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket that
    minimally reproduces the question?

    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray wrote:

    As of 1.6.2 (yes, not quite current, though I did not see anything in the
    changelog that addressed this), when using roles, each role is called
    relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined by
    the host var 'hostlist'. This is all well and good; however, in our current
    setup, we have roles for generic functionality (e.g. apache, mysql, etc)
    and also server specific playbooks. These server specific playbooks have a
    few one-off tasks that do not apply to other roles. One of these might look
    like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a variable in
    the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the "base"
    role would only have the absolutely necessary files and all specific files
    could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also here"
    directive, nor any sort of inheritance that currently accomplishes this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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+unsubscribe@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/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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+unsubscribe@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/CA%2BnsWgzGWDS7hSr%3DdCKE-CfeHPyGoW%2BBKy3sKd-Gs93tsuKSuA%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mike Ray at Jul 30, 2014 at 6:12 pm
    It might take me a few days yet, but I will try to create a minimalist one
    that shows what I am talking about.
    On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote:

    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket that
    minimally reproduces the question?


    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray <mike.jo...@gmail.com
    <javascript:>> wrote:
    As of 1.6.2 (yes, not quite current, though I did not see anything in the
    changelog that addressed this), when using roles, each role is called
    relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined by
    the host var 'hostlist'. This is all well and good; however, in our current
    setup, we have roles for generic functionality (e.g. apache, mysql, etc)
    and also server specific playbooks. These server specific playbooks have a
    few one-off tasks that do not apply to other roles. One of these might look
    like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a variable
    in the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the "base"
    role would only have the absolutely necessary files and all specific files
    could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also
    here" directive, nor any sort of inheritance that currently accomplishes
    this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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-proje...@googlegroups.com <javascript:>.
    To post to this group, send email to ansible...@googlegroups.com
    <javascript:>.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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+unsubscribe@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/a176d8b5-3b4e-422e-a94d-103a6386ec21%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mike Ray at Aug 4, 2014 at 6:01 pm
    Please make sure you check out the README as I believe I not only better
    explain the "problem" but note ways I could make it work with the existing
    Ansible (things I hadn't realized when I made this request).

    Basically, this is a pretty specific request to slightly expand
    functionality and is probably not worth the time-investment.

    But, since I promised it, here is a github where you can see a skinned down
    example: https://github.com/rayvenshire/Ansible/tree/master/relative_search_paths_3j0SYZN4r3Q
    On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote:

    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket that
    minimally reproduces the question?


    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray <mike.jo...@gmail.com
    <javascript:>> wrote:
    As of 1.6.2 (yes, not quite current, though I did not see anything in the
    changelog that addressed this), when using roles, each role is called
    relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined by
    the host var 'hostlist'. This is all well and good; however, in our current
    setup, we have roles for generic functionality (e.g. apache, mysql, etc)
    and also server specific playbooks. These server specific playbooks have a
    few one-off tasks that do not apply to other roles. One of these might look
    like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a variable
    in the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the "base"
    role would only have the absolutely necessary files and all specific files
    could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also
    here" directive, nor any sort of inheritance that currently accomplishes
    this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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-proje...@googlegroups.com <javascript:>.
    To post to this group, send email to ansible...@googlegroups.com
    <javascript:>.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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+unsubscribe@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/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael DeHaan at Aug 4, 2014 at 8:14 pm
    You lost me on sentence #2 about inheritance, as I'm unclear how
    inheritance applies to directories.

    "It would be nice if one role could inherit another's directory structure."

    Looking at the two YAML files, I see both "broken" and "working" contain
    the same playbook basically:



    On Mon, Aug 4, 2014 at 2:01 PM, Mike Ray wrote:

    Please make sure you check out the README as I believe I not only better
    explain the "problem" but note ways I could make it work with the existing
    Ansible (things I hadn't realized when I made this request).

    Basically, this is a pretty specific request to slightly expand
    functionality and is probably not worth the time-investment.

    But, since I promised it, here is a github where you can see a skinned
    down example:
    https://github.com/rayvenshire/Ansible/tree/master/relative_search_paths_3j0SYZN4r3Q
    On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote:

    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket that
    minimally reproduces the question?

    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray wrote:

    As of 1.6.2 (yes, not quite current, though I did not see anything in
    the changelog that addressed this), when using roles, each role is called
    relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined by
    the host var 'hostlist'. This is all well and good; however, in our current
    setup, we have roles for generic functionality (e.g. apache, mysql, etc)
    and also server specific playbooks. These server specific playbooks have a
    few one-off tasks that do not apply to other roles. One of these might look
    like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a variable
    in the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the "base"
    role would only have the absolutely necessary files and all specific files
    could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also
    here" directive, nor any sort of inheritance that currently accomplishes
    this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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-proje...@googlegroups.com.
    To post to this group, send email to ansible...@googlegroups.com.

    To view this discussion on the web visit https://groups.google.com/d/
    msgid/ansible-project/62e923b1-f78a-4fc8-98a3-
    b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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+unsubscribe@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/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.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+unsubscribe@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/CA%2BnsWgzJRLW%3DsSdfhY169UEhuCLXkWtSZDp%3D5i4kbyTWS3kZ%2BA%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael DeHaan at Aug 4, 2014 at 8:14 pm
    Gmail sent this email early, one sec while I finish it :)



    On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan wrote:

    You lost me on sentence #2 about inheritance, as I'm unclear how
    inheritance applies to directories.

    "It would be nice if one role could inherit another's directory
    structure."

    Looking at the two YAML files, I see both "broken" and "working" contain
    the same playbook basically:



    On Mon, Aug 4, 2014 at 2:01 PM, Mike Ray wrote:

    Please make sure you check out the README as I believe I not only better
    explain the "problem" but note ways I could make it work with the existing
    Ansible (things I hadn't realized when I made this request).

    Basically, this is a pretty specific request to slightly expand
    functionality and is probably not worth the time-investment.

    But, since I promised it, here is a github where you can see a skinned
    down example:
    https://github.com/rayvenshire/Ansible/tree/master/relative_search_paths_3j0SYZN4r3Q
    On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote:

    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket that
    minimally reproduces the question?

    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray wrote:

    As of 1.6.2 (yes, not quite current, though I did not see anything in
    the changelog that addressed this), when using roles, each role is called
    relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined
    by the host var 'hostlist'. This is all well and good; however, in our
    current setup, we have roles for generic functionality (e.g. apache, mysql,
    etc) and also server specific playbooks. These server specific playbooks
    have a few one-off tasks that do not apply to other roles. One of these
    might look like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a variable
    in the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the
    "base" role would only have the absolutely necessary files and all specific
    files could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also
    here" directive, nor any sort of inheritance that currently accomplishes
    this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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-proje...@googlegroups.com.
    To post to this group, send email to ansible...@googlegroups.com.

    To view this discussion on the web visit https://groups.google.com/d/
    msgid/ansible-project/62e923b1-f78a-4fc8-98a3-
    b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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+unsubscribe@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/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.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+unsubscribe@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/CA%2BnsWgwCb89wv3Yqiy_FpSUd722tXu%3Doh_WDHKF1EasY5D%2BA9Q%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael DeHaan at Aug 4, 2014 at 8:16 pm
    Basically my question is

    (A) how is "broken" different from "working" in your two examples?

    If I try to step back to the higher level, I think this may be saying
    something like "if role dependencies are used, look for files also in the
    paths the dependent role might be"?

    Though I'm having trouble fitting a use case to that one. (Also, role
    deps were never meant to be an inheritance mechanism, they are a dependency
    mechanism - run this before that).



    On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan wrote:

    Gmail sent this email early, one sec while I finish it :)



    On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan wrote:

    You lost me on sentence #2 about inheritance, as I'm unclear how
    inheritance applies to directories.

    "It would be nice if one role could inherit another's directory
    structure."

    Looking at the two YAML files, I see both "broken" and "working" contain
    the same playbook basically:




    On Mon, Aug 4, 2014 at 2:01 PM, Mike Ray <mike.joseph.ray@gmail.com>
    wrote:
    Please make sure you check out the README as I believe I not only better
    explain the "problem" but note ways I could make it work with the existing
    Ansible (things I hadn't realized when I made this request).

    Basically, this is a pretty specific request to slightly expand
    functionality and is probably not worth the time-investment.

    But, since I promised it, here is a github where you can see a skinned
    down example:
    https://github.com/rayvenshire/Ansible/tree/master/relative_search_paths_3j0SYZN4r3Q
    On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote:

    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket
    that minimally reproduces the question?


    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray <mike.jo...@gmail.com>
    wrote:
    As of 1.6.2 (yes, not quite current, though I did not see anything
    in the changelog that addressed this), when using roles, each role is
    called relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined
    by the host var 'hostlist'. This is all well and good; however, in our
    current setup, we have roles for generic functionality (e.g. apache, mysql,
    etc) and also server specific playbooks. These server specific playbooks
    have a few one-off tasks that do not apply to other roles. One of these
    might look like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a
    variable in the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the
    "base" role would only have the absolutely necessary files and all specific
    files could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also
    here" directive, nor any sort of inheritance that currently accomplishes
    this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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-proje...@googlegroups.com.
    To post to this group, send email to ansible...@googlegroups.com.

    To view this discussion on the web visit https://groups.google.com/d/
    msgid/ansible-project/62e923b1-f78a-4fc8-98a3-
    b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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+unsubscribe@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/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.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+unsubscribe@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/CA%2BnsWgw8unMXDjBAMa4aSX-paid%3D6seh97LYnpJHXa322EDV_g%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mike Ray at Aug 5, 2014 at 2:53 pm
    "Broken" and "working" are exactly the same except that the certificate
    that "working" uses is within the apache2-ssl directory structure (i.e.
    roles/apache2/files/external.crt) whereas "broken" has its own certificate
    in its own directory structure (i.e.
    roles/servers/broken/files/IN_MY_DIRECTORY.crt) . This is the only
    difference in this example.

    While technically I did not setup role dependencies (according to
    documentation
    http://docs.ansible.com/playbooks_roles.html#role-dependencies), that is in
    an essence how I am using the apache-ssl playbook in this example. And I
    believe you have accurately stated what I attempted to by taking a step
    back, let me restate it and make sure we understand each other: "for each
    role (r) that is listed as a dependency of some other role (x), when
    running that role (r), prioritize files provided by role (x)".

    The use cases are for when a file would have to be so different from the
    generic template that it could not be easily mangled or assembled using
    current modules or that each instance of that file is unique such that no
    template exists. So in my example, "external.crt" and "IN_MY_DIRECTORY.crt"
    are two completely different SSL certificates. They have no relation to
    each other (except that they are SSL certificates), and no relation to the
    generic apache-ssl playbook because they are server specific certificates.

    Yes, I do agree that it is odd for a dependency to "inherit" the
    dependent's directory structure.

    As I mentioned in the readme, there are sufficiently valid ways to cope
    with this problem, so if this is too odd, pointless or "un-Ansible-like",
    it won't stop my setup :)
    On Monday, August 4, 2014 3:16:24 PM UTC-5, Michael DeHaan wrote:

    Basically my question is

    (A) how is "broken" different from "working" in your two examples?

    If I try to step back to the higher level, I think this may be saying
    something like "if role dependencies are used, look for files also in the
    paths the dependent role might be"?

    Though I'm having trouble fitting a use case to that one. (Also, role
    deps were never meant to be an inheritance mechanism, they are a dependency
    mechanism - run this before that).




    On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan <mic...@ansible.com
    <javascript:>> wrote:
    Gmail sent this email early, one sec while I finish it :)




    On Mon, Aug 4, 2014 at 4:14 PM, Michael DeHaan <mic...@ansible.com
    <javascript:>> wrote:
    You lost me on sentence #2 about inheritance, as I'm unclear how
    inheritance applies to directories.

    "It would be nice if one role could inherit another's directory
    structure."

    Looking at the two YAML files, I see both "broken" and "working" contain
    the same playbook basically:




    On Mon, Aug 4, 2014 at 2:01 PM, Mike Ray <mike.jo...@gmail.com
    <javascript:>> wrote:
    Please make sure you check out the README as I believe I not only
    better explain the "problem" but note ways I could make it work with the
    existing Ansible (things I hadn't realized when I made this request).

    Basically, this is a pretty specific request to slightly expand
    functionality and is probably not worth the time-investment.

    But, since I promised it, here is a github where you can see a skinned
    down example:
    https://github.com/rayvenshire/Ansible/tree/master/relative_search_paths_3j0SYZN4r3Q
    On Tuesday, July 29, 2014 4:04:14 PM UTC-5, Michael DeHaan wrote:

    I'm having trouble parsing this one, sorry.

    Would it be possible to see a git repo or something for this ticket
    that minimally reproduces the question?


    On Tue, Jul 29, 2014 at 12:57 PM, Mike Ray <mike.jo...@gmail.com>
    wrote:
    As of 1.6.2 (yes, not quite current, though I did not see anything
    in the changelog that addressed this), when using roles, each role is
    called relative to its own directory.

    E.g.

    playbook1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: mysql


    Both apache2 and mysql roles will be called against the hosts defined
    by the host var 'hostlist'. This is all well and good; however, in our
    current setup, we have roles for generic functionality (e.g. apache, mysql,
    etc) and also server specific playbooks. These server specific playbooks
    have a few one-off tasks that do not apply to other roles. One of these
    might look like:

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    Currently with our apache playbook, we allow for overloading a
    variable in the top-level playbook to change with SSL certificate is used.

    server1.yml :
    ---
    - hosts: '{{ hostlist }}'
    remote_user: root
    roles:
    - role: apache2
    - role: servers/myserver

    vars:
    - certificate: "not_default_cert.crt"

    However, this means when the apache2 playbook runs it will expand {{
    certificate }} to "not_default_cert.crt" and the only way it would work is
    if that certificate exists in the apache2 folder directory (e.g.
    roles/apache2/files/not_default_cert.crt).

    If there is only one such file, it won't ever be too bad, but if many
    servers needed to overload that file, we'd end up with many "extra" files
    in that directory that really don't apply to that role. It would be nicer
    if those files could reside in their own server specific directory (e.g.
    roles/servers/myserver/files/not_default_cert.crt). That way the
    "base" role would only have the absolutely necessary files and all specific
    files could reside within the server's playbook to which they belonged.

    To my understanding there is no such "search for files here and also
    here" directive, nor any sort of inheritance that currently accomplishes
    this.

    As stated before, I am running 1.6.2, so if this functionality is
    implemented, I apologize, and I will upgrade when I have the chance.

    If others have come across this problem and have a different
    organizational implementation that avoids this issue, I'd love to hear it.

    --
    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-proje...@googlegroups.com.
    To post to this group, send email to ansible...@googlegroups.com.

    To view this discussion on the web visit https://groups.google.com/d/
    msgid/ansible-project/62e923b1-f78a-4fc8-98a3-
    b5b2cebe8d81%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/62e923b1-f78a-4fc8-98a3-b5b2cebe8d81%40googlegroups.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-proje...@googlegroups.com <javascript:>.
    To post to this group, send email to ansible...@googlegroups.com
    <javascript:>.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/31cd53d3-d6fc-4903-b1f0-cd77fd9356e8%40googlegroups.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+unsubscribe@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/eec47dab-69e1-4e07-876c-5983b5fcfe6a%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupansible-project @
postedJul 29, '14 at 6:29p
activeAug 5, '14 at 2:53p
posts8
users2

2 users in discussion

Michael DeHaan: 4 posts Mike Ray: 4 posts

People

Translate

site design / logo © 2022 Grokbase