Hi,
I hoped for the following to work from a playbook:
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?
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:
“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.
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 
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 - 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.
" 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.
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.