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... On Thu, Aug 24, 2023 at 1:25 PM Todd Lewis <[email protected]> wrote: > 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.*" > > On 8/24/23 11:46 AM, Dick Visser wrote: > > 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 > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAF8BbLZrDQMwq6HnJssyZhAWXMP526_PtvfS8aE_m2Xpx_WUsg%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CAF8BbLZrDQMwq6HnJssyZhAWXMP526_PtvfS8aE_m2Xpx_WUsg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > Todd > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/9965b2ab-8562-f254-5a80-950e971308e1%40gmail.com > <https://groups.google.com/d/msgid/ansible-project/9965b2ab-8562-f254-5a80-950e971308e1%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAPvDwos4tBUbW9TQOoVoUd_%2Bi0FKu6DsNLK%2BSj4r0d1GdGgQjA%40mail.gmail.com.
