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.
