# How to detect which role called an other role in case of role dependency **URL:** \ **Category:** Ansible Project\ **Created:** [April 10, 2017, 12:58pm UTC](https://forum.ansible.com/t/how-to-detect-which-role-called-an-other-role-in-case-of-role-dependency/24179 "2017-04-10T12:58:41Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![gabrioux](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@gabrioux](https://forum.ansible.com/u/gabrioux)\ **Post date:** [April 10, 2017, 12:58pm UTC](https://forum.ansible.com/t/how-to-detect-which-role-called-an-other-role-in-case-of-role-dependency/24179/1 "2017-04-10T12:58:41Z")
Hi, I have a playbook with many roles plus a common role that is used by each other roles. Basically, this common role is used because I have some tasks that are applicable for all roles, obviously, I don’t want to rewrite these tasks as many time as I have a role. Recently I encountered a case where I need a task to be played for all roles except only one. Therefore, I’m looking for a way to detect which role issued the call to the common role due to dependency so I could filter when to skip the task or not with a simple `when` statement. ` ├── roles │ ├── common │ │ ├── defaults │ │ │ └── main.yml │ │ └── tasks │ │ ├── main.yml │ │ └── test.yml │ ├── first\_role │ │ ├── meta │ │ │ └── main.yml │ │ └── tasks │ │ └── main.yml │ └── second\_role │ ├── meta │ │ └── main.yml │ └── tasks │ └── main.yml └── site.yml ` The only way I see at the moment to achieve that would be something like following: ` # ./hosts[group1] laptop ansible\_host=127.0.0.1 ` ` # ./site.yml ---
**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\ **Post date:** [April 13, 2017, 3:29pm UTC](https://forum.ansible.com/t/how-to-detect-which-role-called-an-other-role-in-case-of-role-dependency/24179/2 "2017-04-13T15:29:57Z")
This sounds like you're re-discovering why OOP is such a pain in the arse. Sorry to be glib but I see this a lot and it's usually easier for everyone if you just avoid the whole meta dependency thing altogether, it's always a maintenance hassle. If you get this to work it's just another maintenance headache for you or the next guy who maintains this playbook. ---
**Author:** ![Mark\_Phillips](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@Mark\_Phillips](https://forum.ansible.com/u/Mark_Phillips)\ **Post date:** [April 13, 2017, 4:44pm UTC](https://forum.ansible.com/t/how-to-detect-which-role-called-an-other-role-in-case-of-role-dependency/24179/3 "2017-04-13T16:44:24Z")
This. I always used to suggest to people – strongly – that they avoid using meta to pull in other roles, because it’s frankly unkind to your colleagues. Role dependency paths are sooo much easier to visualise if you just list them in the order you need them in a parent play. Simples! ---
**Author:** ![azaghal](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/azaghal/32/4743_2.png) [@azaghal](https://forum.ansible.com/u/azaghal)\ **Post date:** [April 18, 2017, 6:34pm UTC](https://forum.ansible.com/t/how-to-detect-which-role-called-an-other-role-in-case-of-role-dependency/24179/4 "2017-04-18T18:34:17Z")
> Hi, > > I have a playbook with many roles plus a common role that is used by > each other roles. > Basically, this common role is used because I have some tasks that > are applicable for all roles, obviously, I don't want to rewrite > these tasks as many time as I have a role. > Recently I encountered a case where I need a task to be played for > all roles except only one. Therefore, I'm looking for a way to detect > which role issued the call to the common role due to dependency so I > could filter when to skip the task or not with a simple `when` > statement. For start, I would suggest looking at this not from perspective of what role depends on the common role, but instead what task in the common role needs to be optional. The optional tasks performed could be viewed as optional "features" of a role. I.e. when you pass in the parameter to the "common" role, it should be more along the lines of "enable\_BLAH", "operation\_mode" or something similar. You want to put emphasis on what it is that will get run or not. > 1/ The fact that I need to hardcode the rolename is not something > really clean I think. As mentioned above, use a more logical name for the parameter. In this specific case you probably want to have a boolean (True/False) value for it. > 2/ I'm obliged to declare a default variable for `parent_role` to > avoid an error message : > > "The error was: 'parent\_role' is undefined" > > Indeed, when my common role is played and was not called by my role > that doesn't need to exclude the task from being played, I'll get > this error since I do not pass the `parent_role` variable from the > other roles. Declaring defaults for roles is a perfectly ok thing to do - just keep in mind what I wrote above apropos naming the parameter and its syntax. As a side-note, there are some other ways to handle defaults for undefined variables, like (although, I would say it is better to declare values in defaults/main.yml instead): [http://docs.ansible.com/ansible/playbooks\_filters.html#defaulting-undefined-variables](http://docs.ansible.com/ansible/playbooks_filters.html#defaulting-undefined-variables) There is also the "when: foo is defined" syntax (which can be combined with logical and/or as well). But you probably don't need it for your use-case 🙂 > Maybe someone know a nicer way to do this ? For an alternative to meta dependencies (although I have not tried this myself, so take it with a grain of salt), have a look at: [http://docs.ansible.com/ansible/include\_role\_module.html](http://docs.ansible.com/ansible/include_role_module.html) I would find the include\_role module more useful in cases where you want to control ordering in more complex way than just the "meta deps first" -\> "then this role". Finally, you had two replies related to avoid dependencies via meta, something you should consider as well (I thought it'd be nice to provide at least one more way to handle things 🙂 Best regards