Very basic initial tags support (long) and future plans around tags

Archives Ansible Project
1

Pushed some code to support "tags" on resources, which are an optional thing you can use only if you want them.

Long email as I attempt to explain the concept and my thinking behind it…which is not new in configuration management tools, but how it applies to ansible is new, and
not everyone may have seen it somewhere else.

=== Part One ===

The idea behind tags is to be able to run only specific parts of a playbook.

For instance, assume we describe our entire infrastructure in a playbook, mapping each "like" group of systems to particular roles, as represented by include files,
and have one playbook called site.yml:

- hosts: webservers
  tasks:
    - include: tasks/common.yml
    - include: tasks/apache.yml
   
- hosts: dbservers
  tasks:
     - include: tasks/common.yml
     - include: tasks/apache.yml

What happens if I just want to change the NTP server address on all my servers, very quickly? Well, I don't need to run everything, I just want to run
a particular step in tasks/common.yml -- but not all of them.

So I write that individual task like this:

- name: update ntp server config
  action: template src=templates/ntp.yml dest=/etc/ntp.conf
  tags: ntp

(Note that I could have applied multiple tags by using a YAML list of strings for "tags", but it also takes a string to avoid surprises)

If I run the playbook normally, it does everything to all of my machines:

     ansible-playbook site.yml

Though I can also choose to just run the NTP steps

     ansible-playbook site.yml --tags ntp

If I want more than one tag, I can do that too:

    ansible-playbook site.yml -- tags "ntp,acme"

2

- include: "tasks/common.yml as common"

We already have a facility for specifying variables into an include file, for purposes like so:

- include: wordpress.yml user=timmy
- include: wordpress.yml user=bob

So, might as well just do this:

- include: foo.yml tags=a,b,c

And reuse the existing syntax we have in the language

3

Last email for tonight.

the include syntax for tags now works, like this:

include: tasks/common.yml tags=common

And further, the tags code is now super-smart, and will not run a play if none of the tags specified in the play would run.
This means it's super optimized and won't even run the setup step.

If you had all your hosts in your entire infrastructure in one playbook, and just wanted to run the apache related steps, on machines that happened to care about such things, you could now do this.

(This seems to imply, I think, that if you specify "tags" as an element on a play record, this implies all the tasks in the play are automatically assumed to be tagged with that element. I will open a separate ticket to add this.)

You can see all this illustrated here: https://github.com/ansible/ansible/blob/devel/examples/playbooks/tags.yml

4

Pushed some code to support "tags" on resources

Excellent!

        -JP

5

This is exactly what would be needed in our environment. I didn't fully grasp the concept of tags when you mentioned them, but the 3 part explanation captures the various use-cases I was considering when including plays in playbooks.

So I can't wait to test part two and three on our environment.

Thanks !

6

Thanks, Michael, I was about to hack something experimental to try do just this! Love it when people do my work for me!!