Another ways to have multiple actions in the single handler in Ansible

This is an endless story: your handler need two (or more) actions, and you are allowed to have only one. Because block is not a valid action for a handler.

I’ve wrote an article about the most powerful way to solve this some time ago. (Tl;dr; use include_tasks as action in the handler and put anything you want in the included tasklist).

But it’s too powerful and it involves a hex you don’t want to cast (include, include, I afraid of you…).

So, here are three (less powerful but more elegant) ways to have multiple actions inside of a single handler.

Unload/load pattern

This is a very special case when you want to do something and instantly do something opposite. modprobe state=absent and modprobe state=present is a good example for a handler for changes in modprobe config.

- name: reload kvm-intel module
  modprobe: name=kvm-intel state={{ item }}
  loop:
    - absent
    - present

As you can see, we just use ‘loop’ and changing state. It works as magic, moreover, it does not involve bleeding edge features of Ansible.

Abusing ‘action’

If you can change item, you can abuse the action argument for the task in Ansible:

- hosts: localhost
  tasks:
   - debug:
     changed_when: true
     notify: do
  handlers:
    - name: do
      action:
        module: '{{ item.module }}'
      args: '{{ item.args }}'
      loop:
        - module: debug
          args:
            msg: 'hello here'
        - module: setup
          args: gather_subset=network
        - module: file
          args:
            path: /tmp/foobar
            state: touch

Technically you can do this, but I hardly can image a situation when such travesty would be justified. Moreover, you get warning from Ansible “Using a variable for a task’s ‘args’ is unsafe in some situations” and you can’t do anything about it.

Chaining notifications

You can add ‘notify’ to any handler. If that handler causes a changed state, it notifies the next handler in the chain.

This trick is absolutely legal, but it has a special property: a chain stops as soon as any action in that chain is ‘no changes’. This can be a desirable behavior, or it can cause you some headache at debug time. Use with caution:

- hosts: localhost
  tasks:
   - debug:
     changed_when: true
     notify: stage1
  handlers:
    - name: stage1
      file: path=/tmp/foo state=touch
      notify: stage2
    - name: stage2
      file: path=/tmp/foo state=file
      notify: stage3
    - name: stage3
      fail:
        msg: 'impossible!'

As you may guess, this example normally should not trigger ‘stage3’ (if there is no race condition with file removal).

Conclusion

Out of those examples, only the first is completely reasonable (it provides under-delivered functions of module), two others I consider as acts of despair. If you can, try to avoid them.