include search path from a "roled" play

[Руслан Закиров]

Hi,

I hoped for the following to work from a playbook:

- hosts: backends

  roles:

    - common

    - perl-app

  tasks:

    - include: a_task_that_sits_in_xxx_role.yml

But I get:

ERROR: file could not read: .../my-ansible/a_task_that_sits_in_xxx_role.yml

What I expected is that an include in a playbook will search for a task to include in play's roles.

Is it a bug?

[Michael DeHaan]

It's not a bug.   

It's also a little weird, it's not expected that you would manually include a task file from a role directory without using roles, but if you wanted to, you would have to path it in the various subdirectories.

--
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/67cb019c-471b-46ca-82d0-46760f8f4677%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

["F.L. Jonathan Araña Cruz"]

On 26/06/14 14:25, Michael DeHaan wrote:

It's not a bug.   

It's also a little weird, it's not expected that you would manually include a task file from a role directory without using roles, but if you wanted to, you would have to path it in the various subdirectories.

Would be great to have a magic variable to obtain the path to roles tasks, to allow for things like:

- hosts: hosts

  roles:

    - role-apache

    - role-other

  tasks:

    - include: "{{roles_paths['role-apache']}}/create_virtualhost.yml" servername=example.com

There's an issue asking for this, although a bit tangled: https://github.com/ansible/ansible/issues/6955

On Wed, Jun 25, 2014 at 7:03 AM, Руслан Закиров <r...@sports.ru> wrote:

Hi,

I hoped for the following to work from a playbook:

- hosts: backends

  roles:

    - common

    - perl-app

  tasks:

    - include: a_task_that_sits_in_xxx_role.yml

But I get:

ERROR: file could not read: .../my-ansible/a_task_that_sits_in_xxx_role.yml

What I expected is that an include in a playbook will search for a task to include in play's roles.

Is it a bug?

--
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/67cb019c-471b-46ca-82d0-46760f8f4677%40googlegroups.com.
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.
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/CA%2BnsWgw_Tu3Jbf9-JsYLp6Kc_h%3D4Vchy5jabzavuE21NRMq1rw%40mail.gmail.com.

[Michael DeHaan]

"Would be great to have a magic variable to obtain the path to roles tasks, to allow for things like:"

I feel it would be pretty esoteric and infrequently used, we tend to push back on extra magic until enough use cases for them start to appear.

Usually roles don't import tasks straight out of other roles, and would use role dependencies in the cases where they did.

You should be able to know the relative pathing in nearly all cases though.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/53AC502A.6010300%40faita.net.

[Dmitry Makovey]

I'm facing somewhat similar challange, with a workaround - I've used the full-path expression, but in my case I have single template that is used for 2 roles. So I assumed one role to be primary and store such template and the other role is using roles/my_pri_role/templates/foo.j2 I guess for common templates one could use  top-level "templates" dir or somesuch, but if felt bit more natural to store it within appropriate roles. I do realize symlinks could've helped, but with version controll - that is not the most elegant solution either IMO. 

... just bringing more usecases ;)

["F.L. Jonathan Araña Cruz"]

On 26/06/14 17:59, Michael DeHaan wrote:

"Would be great to have a magic variable to obtain the path to roles tasks, to allow for things like:"

I feel it would be pretty esoteric and infrequently used, we tend to push back on extra magic until enough use cases for them start to appear.

Usually roles don't import tasks straight out of other roles, and would use role dependencies in the cases where they did.

Indeed I'd like a role to soft-depend on other. For example, a munin role may ask apache role to create a virtualhost, if it finds apache is available.

Other example is an apache role that may ask fail2ban role, if available, to enable jails for the ports it manages.

My workaround for this is to hihack action plugins - https://github.com/sbitmedia/ansible-monit#leverage-monit-in-your-roles

You should be able to know the relative pathing in nearly all cases though.

Yes, from my playbooks (or roles) I know the relative path to anything, but I can't assume anythin for a role I want to contribute.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyrBeMs%3DdvcHh821LM6HiM3PyMHRf-T2xD5vdn8Zq_Tyw%40mail.gmail.com.

[Michael DeHaan]

" For example, a munin role may ask apache role to create a virtualhost, if it finds apache is available."

Role dependencies can include "when" statements.   The conditionals will be applied to each task in the role, so the parameters would need to be loaded first, i.e in your role dependencies:

{ role: apache, when: has_apache }

Since these happen before the role, you would need to set "has_apache" via register or other means prior to including the role that had this dependency.

However, in most cases, this is a little too complicated.

Why do munin machines in your infrastructure only sometimes have Apache available?

I'd probably try to fix that by enforcing consistency with Ansible, rather than making it behave too conditionally.

It's almost always cleaner to say "there shall be X" and make it so, rather than make some things depend on the state of remote infrastructure, which is variable, and then you don't know what you've got. 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/53AD5E8E.6030205%40faita.net.

["F.L. Jonathan Araña Cruz"]

On 27/06/14 13:49, Michael DeHaan wrote:

" For example, a munin role may ask apache role to create a virtualhost, if it finds apache is available."

Role dependencies can include "when" statements.   The conditionals will be applied to each task in the role, so the parameters would need to be loaded first, i.e in your role dependencies:

{ role: apache, when: has_apache }

Since these happen before the role, you would need to set "has_apache" via register or other means prior to including the role that had this dependency.

However, in most cases, this is a little too complicated.

Why do munin machines in your infrastructure only sometimes have Apache available?

I'm just thinking in terms of contributed roles. I may want to contribute a munin role that configures a virtualhost only if it detects the user is including a compatible apache role, because a user may want to use my contributed munin role, but not my contributed apache.
Munin-apache is just an example. A more generalized use case: services that may declare fail2ban jails, or monit checks if they detect the providing roles are already included.

Nevertheless, I think I've grokked (or resigned to) ansible philosophy and just wanted to point some things that IMHO may help it be a better tool.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzund%2BCfte7iYWB4f6ZD9GUnOkNpszk4jk6C7cR%2BD-wZA%40mail.gmail.com.