Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template handler name #41837

Merged
merged 1 commit into from Jun 25, 2018
Merged

Template handler name #41837

merged 1 commit into from Jun 25, 2018

Conversation

mkrizek
Copy link
Contributor

@mkrizek mkrizek commented Jun 22, 2018

SUMMARY

Fixes #15505
Fixes #17922
Fixes #19898

ISSUE TYPE
  • Bugfix Pull Request
COMPONENT NAME

handlers

ANSIBLE VERSION
devel
ADDITIONAL INFORMATION

@mkrizek mkrizek requested review from jimi-c, sivel and bcoca June 22, 2018 11:53
@mkrizek mkrizek added this to IN PROGRESS in CEM Jun 22, 2018
@ansibot ansibot added affects_2.7 This issue/PR affects Ansible v2.7 bug This issue/PR relates to a bug. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Jun 22, 2018
@mkrizek mkrizek removed the needs_triage Needs a first human triage before being processed. label Jun 22, 2018
@bcoca
Copy link
Member

bcoca commented Jun 22, 2018

won't notifying fail since the handler name used does not exist until you run handlers?

or is this only meant to work with listen:?

@mkrizek
Copy link
Contributor Author

mkrizek commented Jun 22, 2018

I think they are notified by their uuid, so notifying shouldn't fail, no? Anyway, the following works:

- hosts: localhost
  gather_facts: no
  vars:
    hname: handler1
  tasks:
    - name: "task to notify {{ hname }}"
      debug:
        msg: "notifying {{ hname }}"
      changed_when: true
      notify: "{{ hname }}"

  handlers:
    - name: "{{ hname }}"
      debug:
        msg: "{{ hname }} called"

There might be a case where it fails I am not aware of.

@bcoca
Copy link
Member

bcoca commented Jun 22, 2018

No, it gets looked up by either name or listen keywords, THEN it is stored by uuid.

The thing is that the current code change is templating at runtime, this is too late, something else is probably already templating at definition time and this change will only affect display.

Tested your example in devel and it 'works' it just doesn't display the templated name.
< RUNNING HANDLER [{{ hname }}] >

In either case, the variable scope matters, host specific vars for example, won't work.

So this change seems fine, its only display purposes, not 'matching' nor 'definition', though i would look to see if you can get the already templated name (needed to trigger handler) vs having to 're template it'

@mkrizek
Copy link
Contributor Author

mkrizek commented Jun 25, 2018

The already templated name does not seem to be stored, it's templated on the lookup [1] and matched with result['_ansible_notify'] (= task.notify which is already templated in TaskExecutor on post_validate). So unsure if I can get it (without making this change bigger and more risky).

https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/strategy/__init__.py#L369

@bcoca bcoca merged commit 8b5283f into ansible:devel Jun 25, 2018
@mkrizek mkrizek deleted the template-handler-name branch June 25, 2018 18:29
@mkrizek mkrizek moved this from IN PROGRESS to DONE in CEM Jun 25, 2018
@ansible ansible locked and limited conversation to collaborators Jun 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.7 This issue/PR affects Ansible v2.7 bug This issue/PR relates to a bug. support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
No open projects
CEM
DONE
3 participants