Problems notifying handlers in another role

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

I don’t know if this is the best way, but I have a role consisting of just handlers that is included as a metal dependency by other roles. This helps me get around having multiple handlers that do the same thing and also allows me to enforce the order that they are run (eg, I have a reboot handler that would be really counterproductive if it ran before other handlers, so it is listed last).

Hi,

Okay, thanks, that does help a little because in the playbook what I
can do is:

- hosts: some_group
  roles:
    - {
        role: app,
        }

- hosts: all
  roles:
    - {
        role: configure,
        }
  handlers:
    - include: roles/app/handlers/main.yml

meaning that the handlers that have to listen for "App config has
changed" can live in the logical place in their own roles, but I do
have to remember to include each of their files.

It still is confusing to me why the handlers in
roles/app/handlers/main.yml are not visible to the tasks in the
other roles unless explicitly included this way.

Thanks,
Andy