Simpler way to define many handlers?

[Dick Visser]

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

[Pierre Daheron]

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

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAF8BbLZrDQMwq6HnJssyZhAWXMP526_PtvfS8aE_m2Xpx_WUsg%40mail.gmail.com.

[Todd Lewis]

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!
--
Todd
"Any tool is a hammer if you use it wrong enough."

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAF8BbLZrDQMwq6HnJssyZhAWXMP526_PtvfS8aE_m2Xpx_WUsg%40mail.gmail.com.

-- 
Todd

[Cody Fawcett]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/9965b2ab-8562-f254-5a80-950e971308e1%40gmail.com.

[Vladimir Botka]

On Thu, 24 Aug 2023 17:46:58 +0200
Dick Visser <dnmv...@gmail.com> wrote:

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

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


--
Vladimir Botka

[Dick Visser]

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