Hello,
Say I have a playbook a bit like this:
- hosts: some_group
roles:
- {
role: app,
}
- hosts: all
roles:
- {
role: configure,
}
That second role "configure" does something that will require the
apache2 service on hosts in some_group to be reloaded. However there
will be multiple other roles that depend on the things that the
"configure" role does, and it won't always be apache2 that needs to
be reloaded. It may be some other software that needs to be
reloaded.
Therefore, I don't think it's correct to put a handler in
roles/configure/handlers/main.yml, because I don't know ahead of
time every possible thing that should be reloaded.
The "app" role does know what needs to be reloaded, so it seems like
the handler should be in roles/app/handlers/main.yml and notified
from the task in roles/configure/tasks/….
Also, as I do not know the exact services that will require
reloading, it seems like I should in fact use "listen:" on the
handler. The idea being that multiple different roles will register
listeners on that event and then they can all fire to reload what
needs reloading.
I put a handler in roles/app/handlers/main.yml like:
- name: Graceful reload apache2
listen: App config has changed
command: /usr/sbin/apache2ctl graceful
When the corresponding notify fires, I get the error that no such
handler exists.
If I put the above handler in the same role as where it is notified
from, i.e. in roles/configure/handlers/main.yml, or add it to the
playbook like:
- hosts: all
roles:
- {
role: configure,
}
handlers:
- name Graceful reload apache2
listen: App config has changed
command: /usr/sbin/apache2ctl graceful
Then it works.
That's not going to work for me though, because I need other roles
to manage software that will also want to be reloaded when "App
config has changed".
I thought that handlers were a global namespace, and the "app" role
comes first so why is its handler not being made available to the
tasks in the "configure" role?
Is there a better pattern for what I am trying to do?
Version 2.7.4.
Thanks,
Andy