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