Listing a host's roles

[ralo...@gmail.com]

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.

[Michael DeHaan]

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

--
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/18e8ba5b-42a9-4f48-a5fa-d2d88a66ec02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[raphael campardou]

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.

> You received this message because you are subscribed to a topic in the

> Google Groups "Ansible Project" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ansible-project/jeu_3t8Nenw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAEVJ8QO%2Bea%3DYC3adzptwY9rQe8yXBg1HAtHoN5H3a0238haSUA%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
http://ralovely.com

[Michael DeHaan]

On Mon, Mar 24, 2014 at 8:38 AM, raphael campardou <ralo...@gmail.com> wrote:

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 :)

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAFzt8g0z5bEwwPqhwyx81UAb0_ZV%3DDHVqDr8Ve49TMmA2Pg9ww%40mail.gmail.com.

[raphael campardou]

>> 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.

> https://groups.google.com/d/msgid/ansible-project/CAEVJ8QMR5f8OQbtWKA8KAVh%2Brm2_zQsuu64mpebm_JDOKCyRdA%40mail.gmail.com.

[Michael DeHaan]

On Mon, Mar 24, 2014 at 9:03 AM, raphael campardou <ralo...@gmail.com> wrote:

>> 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!

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAFzt8g1xQzKX_yLgeJb0KtbaTA4jbAc2V7LL0xJMVFzkbkZMFA%40mail.gmail.com.