# Listing a host's roles **URL:** \ **Category:** Ansible Project\ **Created:** [March 24, 2014, 4:17am UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838 "2014-03-24T04:17:12Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![ralovely](https://avatars.discourse-cdn.com/v4/letter/r/57b2e6/32.png) [@ralovely](https://forum.ansible.com/u/ralovely)\ **Post date:** [March 24, 2014, 4:17am UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838/1 "2014-03-24T04:17:12Z")
Hi. Is there any way to obtain the list of roles a Host will be playing ? Something in the same idea as --list-tasks. In the same way, being able to list the groups of a host, from outside a play (i.e… at the command line) would be nice (parsing the host file can become messy real quick). Thanks. raphael. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [March 24, 2014, 12:30pm UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838/2 "2014-03-24T12:30:02Z")
Yes, the variable “role\_names” contains a list of all role names, as of a 3/11 addition by Brian Coca. You’ll need the development branch. However in most cases (but not always), it’s not needed — plays are intended to map groups to roles, so it’s intended that tests are applied against group membership most of the time. - hosts: webservers roles: - base - webserver - monitored Thus if you were doing an iptables template: {% if inventory\_hostname in groups.webservers %} Is equivalent to: {% if ‘webserver’ in role\_names %} If all machines were to be monitored, it might be nice to even say this: - host: all roles: - base - host: webservers roles: - webserver - host: all roles: - monitored ---
**Author:** ![ralovely](https://avatars.discourse-cdn.com/v4/letter/r/57b2e6/32.png) [@ralovely](https://forum.ansible.com/u/ralovely)\ **Post date:** [March 24, 2014, 12:38pm UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838/3 "2014-03-24T12:38:30Z")
Thanks Michael Nice addition, fresh out of the press. Is there a way ti access it from outside the run of the playbook, like we do --list-tasks. My use case is testing the play books with spec and serverspec. I'd like my test suit to be automated: "for a given host, here is the list of roles that have been applied, test each of them". Or, as you said, a list of groups per host, roles per play, and I can do the mapping myself. (that being said, the role\_names will come handy too). raphael. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [March 24, 2014, 12:53pm UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838/4 "2014-03-24T12:53:45Z")
> Thanks Michael > > Nice addition, fresh out of the press. > Is there a way ti access it from outside the run of the playbook, like > we do --list-tasks. There's not. > My use case is testing the play books with spec and serverspec. > I'd like my test suit to be automated: > "for a given host, here is the list of roles that have been applied, > test each of them". Nope. Though you could --list-tasks and parse out the role names, I guess, or even write a playbook that walked the list of things and generated a config file. I am generally of the opinion that a need for server-spec to verify that Ansible set basic things like file permissions correctly is a sign that Ansible \*does not work\* (which it does) and that it's easier to just call a test script as the last per-host action in your playbook, so that the playbook returns a proper failure code and fails the host. What should be tested is whether the application is running, not that there are 1:1 tests for every step in the playbook -- which is a crazy large amount of extra work for not much more value add. But that's me giving a public service announcement and everyone is welcome to do what they want 🙂 ---
**Author:** ![ralovely](https://avatars.discourse-cdn.com/v4/letter/r/57b2e6/32.png) [@ralovely](https://forum.ansible.com/u/ralovely)\ **Post date:** [March 24, 2014, 1:03pm UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838/5 "2014-03-24T13:03:23Z")
> > Is there a way to access it from outside the run of the playbook, like > > we do --list-tasks. > > There's not. Well, at least I can stop searching 🙂 > > My use case is testing the play books with spec and serverspec. > > I'd like my test suit to be automated: > > "for a given host, here is the list of roles that have been applied, > > test each of them". > > Nope. Though you could --list-tasks and parse out the role names, I > guess, or even write a playbook that walked the list of things and generated > a config file. IIRC, list-tasks doesn't output the role names, only the targeted group. This would be a simple solution to this need, though. Calling a play to generate it might work. I'll try. > I am generally of the opinion that a need for server-spec to verify that > Ansible set basic things like file permissions correctly is a sign that > Ansible \*does not work\* (which it does) and that it's easier to just call a > test script as the last per-host action in your playbook, so that the > playbook returns a proper failure code and fails the host. What should be > tested is whether the application is running, not that there are 1:1 tests > for every step in the playbook -- which is a crazy large amount of extra > work for not much more value add. But that's me giving a public service > announcement and everyone is welcome to do what they want 🙂 I completely agree. We look for other things in our test: - good integration of all the pieces: more service level than app - no regression: there are 5 of us committing regularly, on several different configs for very different client setups - human error It also brings a better overall understanding and forces to ask questions differently. But we are not testing Ansible itself, as you said, it knows how to set permissions on a file 🙂 Thanks again. raphael. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [March 24, 2014, 1:14pm UTC](https://forum.ansible.com/t/listing-a-hosts-roles/14838/6 "2014-03-24T13:14:08Z")
> \>\> Is there a way to access it from outside the run of the playbook, like > \>\> we do --list-tasks. > \> There's not. > IIRC, list-tasks doesn't output the role names, only the targeted group. > This would be a simple solution to this need, though. > Calling a play to generate it might work. I'll try. Oh yeah, this is a thing. The role is added before the task, but not in --list-tasks yet. There's an open ticket, if I recall correctly. > \> I am generally of the opinion that a need for server-spec to verify that > \> Ansible set basic things like file permissions correctly is a sign that > \> Ansible \*does not work\* (which it does) and that it's easier to just > call a > \> test script as the last per-host action in your playbook, so that the > \> playbook returns a proper failure code and fails the host. What > should be > \> tested is whether the application is running, not that there are 1:1 > tests > \> for every step in the playbook -- which is a crazy large amount of extra > \> work for not much more value add. But that's me giving a public > service > \> announcement and everyone is welcome to do what they want 🙂 > > I completely agree. > We look for other things in our test: > - good integration of all the pieces: more service level than app > - no regression: there are 5 of us committing regularly, on several > different configs for very different client setups > - human error > It also brings a better overall understanding and forces to ask > questions differently. > > But we are not testing Ansible itself, as you said, it knows how to > set permissions on a file 🙂 Excellent. I see so many painful-looking Server Spec posts on the internet it's good to be seeing it used to do more useful testing than that -- but I should know that's just part of the internet 🙂 I would hate to feel if people thought they had to write 2x the instructions for every task in Ansible land. Good deal!