Playbooks, roles, and tagging behaviors

93 views
Skip to first unread message

E.C. Raymond

unread,
Sep 23, 2014, 6:24:10 PM9/23/14
to ansible...@googlegroups.com
I am experiencing some strange behavior from what I understand to be applying tags to roles/dependencies. I wrote a facts plugin to gather information about a systems role, and it includes this in the playbook run.  Each system runs a playbook on its own, only managing itself.

# ansible_local facts
127.0.0.1 | success >> {
    "ansible_facts": {
        "ansible_local": {
            "host_roles": {
                "roles": [
                    "APPSERVERS",
                    "COMMON",
 
                ]
            }
        }
    },
    "changed": false
}

# site.yml
---
 - hosts: 127.0.0.1
   connection: local
   gather_facts: yes
   sudo: yes

   roles:
     - { role: appserver,             , when: "'APPSERVERS' in ansible_local.host_roles.roles" }
     - { role: hadoop_jobtracker, when: "'HADOOP_JOBTRACKER' in ansible_local.host_roles.roles" }


# roles/appserver/meta/main.yml
---
  dependencies:
    - { role: managed_interface, tags=initial }

This is the simplified output of my setup. I have a server that is acting with a local run of a playbook, and gathers its roles, and then grabs the dependencies from its role to call the manage_interface role when its tagged as initial.

# command line
ansible-playbook site.yml --tags "initial"

The command runs only its tasks/main.yml and not the dependencies.

When I tried applying at the site.yml level things got really weird. It runs both the appserver and hadoop_jobtracker roles, seemingiy ignoring the "when" statements.

   roles:
     - { role: appserver,               tags: ['initial'], when: "'APPSERVERS' in ansible_local.host_roles.roles" }
     - { role: hadoop_jobtracker, tags: ['initial'], when: "'HADOOP_JOBTRACKER' in ansible_local.host_roles.roles" }

Are there some rules in which these can be applied properly, or am I hacking at the system and making trouble again?

Michael DeHaan

unread,
Sep 23, 2014, 9:57:02 PM9/23/14
to ansible...@googlegroups.com
For starters, can you share what version of Ansible you are using?

Thanks!



--
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/dac2a7a2-a8d7-40b8-b00d-2801ff9289a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

E.C. Raymond

unread,
Sep 24, 2014, 12:41:58 PM9/24/14
to ansible...@googlegroups.com
Hi Michael,

I am using 1.7.1, and tried on latest devel build.

Michael DeHaan

unread,
Sep 24, 2014, 2:30:37 PM9/24/14
to ansible...@googlegroups.com
Ok, please file a bug about this, that the when statements need to be propagated to the role deps.

Thanks!



E.C. Raymond

unread,
Sep 24, 2014, 3:38:24 PM9/24/14
to ansible...@googlegroups.com
Thanks, Michael. One question about this bug/behavior, I want to verify.  If tags are applied at the role level, is it supposed to run each role, regardless of the when statement? 

roles:
     - { role: appserver,               tags: ['initial'], when: "'APPSERVERS' in ansible_local.host_roles.roles" }
     - { role: hadoop_jobtracker, tags: ['initial'], when: "'HADOOP_JOBTRACKER' in ansible_local.host_roles.roles" }

In this case, both appserver and the hadoop_jobtracker roles are applied, disregarding my when statement. Do tags take precendence over other logic?

I am able to workaround this bug by adding an include statement in the tasks for each role, and everything works properly.

E.C. Raymond

unread,
Sep 24, 2014, 5:24:02 PM9/24/14
to ansible...@googlegroups.com
Found the problem was with the key,value passing in the role dependencies:

# roles/appserver/meta/main.yml
---
  dependencies:
    - { role: managed_interface, tags=initial }

Should actually be

# roles/appserver/meta/main.yml
---
  dependencies:
    - { role: managed_interface, tags: ['initial'] }

Everything works as expected once replaced.

Michael DeHaan

unread,
Sep 25, 2014, 7:55:19 AM9/25/14
to ansible...@googlegroups.com
"Thanks, Michael. One question about this bug/behavior, I want to verify.  If tags are applied at the role level, is it supposed to run each role, regardless of the when statement? "

tags and conditionals in ansible are very different things.

If you run all things tagged "X", it would still evaluate the conditionals on all things tagged "X".   Hope this makes sense.

Curious the above typo did not produce an error, can you file a bug about that one?




E.C. Raymond

unread,
Sep 25, 2014, 4:37:15 PM9/25/14
to ansible...@googlegroups.com
Well, it seems there is an issue with the when statement being used in roles as well.

Maybe its because I am constructing my playbooks in a different fashion than the usual documented, but when I run a playbook file that reads:

# site.yml
---
  - hosts: 127.0.0.1
    connection: local

    roles:
      - { role: hadoop_jobtracker, when: "'HADOOP_JOBTRACKER' in ansible_local.host_roles.roles" }
      - { role: appserver,  when: "'APPSERVERS' in ansible_local.host_roles.roles" }

The server this is run on contains local fact, APPSERVERS, but the playbook will run through BOTH roles tasks by order in the playbook, which seems to be ignoring the "when" statement, but skipping unmatched roles. Luckily, it doesn't apply the other roles, but it seems like the when statement doesn't fully apply a restriction in a sense. 

Can anyone else verify that this is the case as well?

David Karban

unread,
Sep 27, 2014, 1:10:40 AM9/27/14
to ansible...@googlegroups.com
Hi,

when you use "when" in role definiton, it basically propagate "when" to every task in the role. So it will run, but skip all tasks inside the role.

David


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



--
David Karban
Specialista na správu linuxových serverů
www.karban.eu
Reply all
Reply to author
Forward
0 new messages