What is the order of role-specific vs. imported handlers and can it be changed?

Get Help
1

Hello,

our handlers are mostly specified in the role itself (like roles/server/handlers/main.yml), but some handlers, which are required in many roles, are specified in a central “library” role (roles/library/handlers/main.yml) and imported into the main playbook (site.yml) in the block, which also runs the role like this

- hosts: all_servers
  name:  "====== SERVER CONFIGURATION ======"
  roles:
    - server
  handlers:
    - ansible.builtin.import_tasks: roles/library/handlers/main.yml

It now seems, that the imported handlers are placed after the role-specific handlers, which breaks some plays, where the library handlers should run before the role-specific handlers, but they run after them (or rather, the play fails, as the handlers didn’t run).

We are aware, that handlers are executed in the order in which they are written in the code, not how they have been called.

We have two questions regarding this situation:

  1. Can it be confirmed, that imported handlers are attached after the list of role-specific handlers?
  2. Is there a way to load imported handlers before the role-specific handlers?

Thanks in advance

2

I’m not sure about the first question but I can give you the answer for the second.

You can make your library role to be a dummy role by making an empty tasks/main.yml. After that, you can call the role together with other roles like so:

roles:
  - library
  - server

This way handlers from library role will be imported into play before all other role handlers and no additional tasks will be executed since library role is empty. You can also define variable defaults in library role which will also be imported without running any tasks.

3

This is not necessary. Roles are not required to contain tasks.

1 Like
4

Hi.
I think a better approach would be to add the handler from the central library role to each respective role. It might be a “little” more work, but this ensures that your roles can function, and are easily shareable, without depending on a “central” role.

1 Like
5

Yes but then when you update the handler code you have to update it in multiple places. With a complex code this quickly leads to high maintenance overhead.

I think the OP presented here a simple example but has much more in mind hence a role that is called a “library” (something complex and shared).

6

Yes, it would be more work, as you have to copy the handler to all the roles that use it, but I believe creating a dependency to a central role causes more complexity :man_shrugging:

1 Like