Intended behavior of variable expansion in role handlers?

Archives Ansible Project
1

Greetings,

I found an unexpected behavior when role variables, with default values defined, are overwritten by role parameters in the playbook. I would like to confirm whether its a bug or working as designed before opening an issue on github.

Here is the test case. I have defined a role to configure multiple instances of a given service. Whenever the instance configuration changes, I need to reload that specific instance informing the path of its configuration file.

roles/some_role/defaults.yml:
instance_name: “default”
instance_conf_file: “/etc/servicename-{{instance_name}}.conf”
instance_param1: “some value”
instance_param2: “some other value”

roles/some_role/tasks.yml:

  • template:
    dest: {{instance_conf_file}}
    src: some_role_conf.j2
    notify:
  • reload conf

roles/some_role/handers.yml:

  • name: reload conf
    command: some command to reload {{instance_name}} {{instance_conf_file}}

In the main playbook, I call the role multiple times with different values for instance parameters, like this:

  • hosts: all
    roles:

first instance “default”

  • role: some_role

second instance

  • role: some_role
    instance_name: “i2”
    instance_param1: “abc”

third instance

  • role: some_role
    instance_name: “i3”
    instance_param1: “xyz”

When configuration of either “i2” or 'i3" is modified, notification to “reload conf” actually goes to handler of first instance (variables in “reload conf” are filled with default values).

I would expect that, like for tasks, variables in role/handlers.yml were evaluated considering the current role environment.

Should I open a bug or this is the intended behavior? If this is the intended behavior, are there any other means to pass instance parameters to handlers?

Any help is appreciated.

Best regards,

2

roles/some_role/defaults.yml:
instance_name: "default"
instance_conf_file: "/etc/servicename-{{instance_name}}.conf"
instance_param1: "some value"
instance_param2: "some other value"

roles/some_role/tasks.yml:
- template:
    dest: {{instance_conf_file}}
    src: some_role_conf.j2
  notify:
    - reload conf

roles/some_role/handers.yml:
- name: reload conf
  command: some command to reload {{instance_name}} {{instance_conf_file}}

In the main playbook, I call the role multiple times with different values
for instance parameters, like this:

- hosts: all
  roles:
    # first instance "default"
    - role: some_role

    # second instance
    - role: some_role
      instance_name: "i2"
      instance_param1: "abc"

   # third instance
    - role: some_role
      instance_name: "i3"
      instance_param1: "xyz"

When configuration of either "i2" or 'i3" is modified, notification to
"reload conf" actually goes to handler of first instance (variables in
"reload conf" are filled with default values).

I would expect that, like for tasks, variables in role/handlers.yml were
evaluated considering the current role environment.

Handlers only run once no mater how many times they are notified and handlers run is triggered after all the roles is finished.

Should I open a bug or this is the intended behavior? If this is the
intended behavior, are there any other means to pass instance parameters to
handlers?

Since handlers is special passing parameters to it is not trivial.

You could instead have "register: result" on the template instead of notify and just have command as a regular task with this added "when: result is changed"