Allow notifying handlers on OTHER HOSTS

[UnitedMarsupials]

Proposal: Allow notifying handlers on OTHER HOSTS

Author: @UnitedMarsupials

Date: 2021-02-27

• Status: New
• Proposal type:
• Targeted release:
• Associated PR:
• Estimated time to implement:

Motivation

When configuring distributed applications, it is quite common, that services on some machines need to be restarted, when something changes on other machines. Unfortunately, the existing handlers-mechanism does not provide for "notifying" remote handlers -- people have to implement their own hacks...

Solution proposal

Expand notify syntax to allow specifying hosts and groups -- still defaulting to the inventory_hostname, of course.

Separating handler-names from the (optional) targets can be done with the simple @.

    name: Change configuration file, that service Foo downloads
      ...
    notify:
       - Restart Foo@slaves
       - Page Operator@pager

Alternatively, if no character can be safely chosen as such a separator -- because a handler's name can contain any character -- just add another clause, such as notify_remote:

    name: Change configuration file, that service Foo downloads
      ...
    notify_remote:
      slaves: Restart Foo
      pager: Page Operator

Documentation (optional)

Depending on the approach chosen (expanding the existing notify-clause vs. creating a new notify_remote), the documentation would need to be updated/created...

[felixfontein]

Not sure whether the work-arounds are not the better solution, since they usually allow better control on when the handlers actually run, but an idea for your proposal: how about not adding a new keyword (notify_remote), but instead allowing the notify entries to be dictionaries:

  - name: Change configuration file, that service Foo downloads
      ...
    notify:
       - name: Restart Foo
         host: slaves
       - name: Page Operator
         host: pager

(Maybe also allow groups or multiple hosts to be mentioned?)

[bcoca]

simple workaround is to have the handler + delegate_to

- name: myhandler
  action: ...
  delegate_to: '{{myhandler_target|default(inventory_hostname)}}'

Then you can set the relationship via a group/host variable or set_fact.

[UnitedMarsupials]

Not sure whether the work-arounds are not the better solution, since they usually allow better control

That's an argument against the whole concept of Ansible :-) Or, indeed, any higher-level languages -- for any programming task.

simple workaround is to have the handler + delegate_to

This would only work for one host, wouldn't it? In my current situation, I need to notify 8 slaves, that the config-file, which they all download from the master, has changed...

Well, I suppose, I can loop the handler -- thanks for the work-around...

I still think, my proposal would be an improvement -- making things easier to read/understand.