Problems notifying handlers in another role

[Andy Smith]

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

[S C Rigler]

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

--
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 post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/20181208155204.GV4569%40bitfolk.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Smith]

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAFbioke1nJ8nyeqCDzKsvZ64MLBp%2Bh05eSD%3Dn7N4f8m1sx3ziQ%40mail.gmail.com.