Simpler way to define many handlers?

Archives Ansible Project
1

Hii,

I have a lot of handlers to restart services, like this:

  • name: smbd_restart
    ansible.builtin.service:
    name: smbd
    state: restarted

  • name: chronyd_restart
    ansible.builtin.service:
    name: chronyd
    state: restarted

  • name: udhcpd_restart
    ansible.builtin.service:
    name: udhcpd
    state: restarted

  • name: dhcpcd_restart
    ansible.builtin.service:
    name: dhcpcd
    state: restarted

  • name: lighttpd_restart
    ansible.builtin.service:
    name: lighttpd
    state: restarted

  • name: sshd_restart
    ansible.builtin.service:
    name: sshd
    state: restarted

  • name: networking_restart
    ansible.builtin.service:
    name: networking
    state: restarted

  • name: hostapd_restart
    ansible.builtin.service:
    name: hostapd
    state: restarted

etc etc

Another pile of them are there for the ‘reload’ state.

According to https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html#using-variables-with-handlers
variables in handler names will likely not work, and variable in listen topic for sure don’t work.

Is there perhaps another way to avoid having a ton of very similar) handlers?

thx

Dick

2

Hi,

only the name seems to change. You could try to list the names of your services and then use a loop. See https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_loops.html
for examples.

Best regards
Pierre

3

I can envision a handler wanting to know for example which of its many possible “listen” strings it was notified by. But therein lies madness, as it could be notified by many different strings. As implemented (last time I looked), a notification results in adding a task to a host’s list of handlers to be run eventually - if it isn’t already on the list. There’s no record kept of any context per notification. Without that sort of metadata, I don’t see a way to implement “smart handlers”.

So lets step back a second and figure out just which problem you want to solve. True, there’s a lot of redundancy in the handlers you cited, so it does feel like there should be a more elegant way to express it. However, they don’t change often, and any one of them is simple enough to maintain.

What I find most compelling about your case is,“Another pile of them are there for the ‘reload’ state” because now you’ve got a slight difference between a couple of places to keep in sync. If this were C instead of YAML, you bet I’d use a preprocessor macro or three.

But this is YAML, and Jinja2, and the marvelous python freakenstein monster that is Ansible. So — and I’m not recommending this, but it is another way to handle it, which is what you asked for — you could use an ansible.builtin.template step to produce a “roles/dynarole/handlers/no-regrets.yml” that contains all your service handlers, then dynamically include that role so that (I think this is how it works) those handlers would then be available for notification from any subsequent tasks in that play. You could split the playbook into a play to generate the handlers files, then subsequent plays to dynamically include or statically import them. Or you could have a separate play/playbook with the sole purpose of generating the largely redundant handlers file that you only run when your table of desired handlers - or the template that consumes it - changes.

I can’t honestly argue that this is a good idea. But so far I haven’t come up with any other suggestions. It’s tempting to try it, if only to say, “Here’s a cool thing that isn’t at all wrong that I’ll never do again.”

Do let us know if you come up with anything!

4

in the task that triggers the handler, is there a way to register a variable and then do a debug in the playbook only when the handler condition is met?

another thought, if the task that triggered the handler is important to track create a specific handler for it, but let the rest just use a generic reload/restart etc…

5

It is not, IMHO, if you want to do it in a single run of a playbook.

It is possible to create handlers from meta-data and template(s) and
then import them. Similar to the concept of the *configure* script
https://en.wikipedia.org/wiki/Configure_script

I'm not saying Ansible should generally adopt this concept. I think,
in some cases such configuration might make the project robuster,
simpler, and easily extendable. FWIW, it's feasible to control some
projects by structured meta-data only
https://ansible-config-light.readthedocs.io/en/latest/qsg.html

6

I eventually settled on having a dedicated role that contains all the handlers we use, and nothing else:

$ tree roles/handlers
roles/handlers
├── README.md
└── handlers
└── main.yml

That is then include early on in the plays:

tasks:

  • name: Ensure shared handler role is imported
    ansible.builtin.import_role:
    name: handlers

It is a bit clunky but it does work and at least the handlers are defined only once.

Dick