Adding loop_control.notify_scope by jtyr · Pull Request #56817 · ansible/ansible

jtyr · 2019-05-22T23:55:24Z

SUMMARY

When using notify in a loop, notification targets for all loop items are triggered even if only single loop item has been changed. This PR is adding a loop_control toggle which allows to trigger notification targets only for changed items of the loop.

To the attention of @bcoca.

ISSUE TYPE

Feature Pull Request

COMPONENT NAME

loop_control

ADDITIONAL INFORMATION

See more details and examples in the documentation included in the PR.

ansibot · 2019-05-22T23:58:41Z

cc @acozine
click here for bot help

bcoca

Also brought up at irc meeting, general consensus is +1 on feature, you might get people bikeshedding on name later though

mkrizek · 2019-06-06T15:22:14Z

        return items

-    def _execute(self, variables=None):
+    def _execute(self, variables=None, notify_scope='task'):


I would turn notify_scope parameter into an instance variable, self._notify_scope. That way you don't have to pass it around.

👍 to making this an instance attribute.

mkrizek · 2019-06-06T15:33:09Z

+                self._task.notify is not None and (
+                    notify_scope != 'per_loop_item' or (
+                        notify_scope == 'per_loop_item' and
+                        result['changed']))):


This is probably just me but I had a hard time parsing that. I would change notify_scope != 'per_loop_item' into notify_scope == 'task' and put it all on the one or two lines maybe. Not a blocker, of course.

This doesn't account for invalid values. I'm wondering if this would be better as a boolean value rather than a string field. Something like notify_per_item with a default of False.

Are there other values for this option that would make it better suited to a string than a boolean?

If we do keep it as a string value, maybe the options could be task, item or task, per_item. Just throwing out ideas.

This is easier to read:

if self._task.notify is not None: if notify_per_loop_item: if result['changed']: result['_ansible_notify'] = self._task.notify else: result['_ansible_notify'] = self._task.notify

Or using the existing string option:

if self._task.notify is not None: if notify_scope not in ['task', 'per_loop_item']: raise AnsibleError("Invalid option '{0}' given for notify_scope. Valid options are " "'task' or 'per_loop_item'".format(to_text(notify_scope))) elif notify_scope == 'per_loop_item': if result['changed']: result['_ansible_notify'] = self._task.notify else: result['_ansible_notify'] = self._task.notify

This doesn't account for invalid values.

Yeah, I realized that when suggested notify_per_item below, too ;-) I was wondering if we had anything like choices for FieldAttribute so we didn't have to check for invalid types here in the code but not that I could find.

The way we have done this before is via something like _validate_debugger. That method effectively does this, but for debugger

Nice. So I'd go with _validate_$whatever_name_we_bikeshed method to check for invalid values. Unless we decide to use a boolean.

mkrizek · 2019-06-06T15:34:50Z

      loop_control:
        extended: yes

+Notification scope in the loop


@acozine @samccann would you mind reviewing the docs part please? Thanks!

mkrizek · 2019-06-06T15:42:13Z

Bikeshedding: can we maybe do something like loop_control.notify_per_item which would be bool, no by default as the current behavior?

Unless we plan to add more options in the future.

samdoran · 2019-06-07T14:35:26Z

        return items

-    def _execute(self, variables=None):
+    def _execute(self, variables=None, notify_scope='task'):


👍 to making this an instance attribute.

samdoran · 2019-06-07T16:09:21Z

+                self._task.notify is not None and (
+                    notify_scope != 'per_loop_item' or (
+                        notify_scope == 'per_loop_item' and
+                        result['changed']))):


This doesn't account for invalid values. I'm wondering if this would be better as a boolean value rather than a string field. Something like notify_per_item with a default of False.

Are there other values for this option that would make it better suited to a string than a boolean?

If we do keep it as a string value, maybe the options could be task, item or task, per_item. Just throwing out ideas.

samdoran · 2019-06-07T16:10:42Z

+                self._task.notify is not None and (
+                    notify_scope != 'per_loop_item' or (
+                        notify_scope == 'per_loop_item' and
+                        result['changed']))):


This is easier to read:

if self._task.notify is not None: if notify_per_loop_item: if result['changed']: result['_ansible_notify'] = self._task.notify else: result['_ansible_notify'] = self._task.notify

Or using the existing string option:

if self._task.notify is not None: if notify_scope not in ['task', 'per_loop_item']: raise AnsibleError("Invalid option '{0}' given for notify_scope. Valid options are " "'task' or 'per_loop_item'".format(to_text(notify_scope))) elif notify_scope == 'per_loop_item': if result['changed']: result['_ansible_notify'] = self._task.notify else: result['_ansible_notify'] = self._task.notify

samdoran · 2019-06-07T17:00:47Z

+
+- name: Set handler variables to known value
+  set_fact:
+    handler_one: null


You could use ~ rather than null.

samdoran · 2019-06-07T17:01:42Z

+- name: Test all handlers were run
+  assert:
+    that:
+      - handler_one != None


Using a test rather than a comparison is a bit more reliable. Types with Jijna can be a pain.

Suggested change

- handler_one != None

- handler_one is not none

samccann

one minor doc nit.

samccann · 2019-06-20T15:58:20Z

+------------------------------
+.. versionadded:: 2.9
+
+By default, if each loop item triggers different notification target, all targets for all items get triggered even if


Suggested change

By default, if each loop item triggers different notification target, all targets for all items get triggered even if

By default, if each loop item triggers a different notification target, all targets for all items get triggered even if

Adding loop_control.notify_scope

48a4dc5

jtyr force-pushed the jtyr-notify_scope branch from 0d81df7 to 48a4dc5 Compare May 23, 2019 00:17

jtyr mentioned this pull request May 23, 2019

Public Ansible Project Meeting Agenda - May 2019 ansible/community#466

Closed

bcoca added P3 Priority 3 - Approved, No Time Limitation and removed needs_triage Needs a first human triage before being processed. labels May 28, 2019

bcoca requested changes May 28, 2019

View reviewed changes

Comment thread lib/ansible/executor/task_executor.py Outdated

ansibot added needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. and removed core_review In order to be merged, this PR must follow the core review workflow. labels May 28, 2019

jtyr force-pushed the jtyr-notify_scope branch 2 times, most recently from 1634bf4 to 2065f8d Compare May 29, 2019 23:20

Don't pass notify_scope via variables + unit test for wrong_value

9158710

jtyr force-pushed the jtyr-notify_scope branch from 2065f8d to 9158710 Compare May 29, 2019 23:37

jtyr mentioned this pull request Jun 6, 2019

Public Ansible Project Meeting Agenda - Jun 2019 ansible/community#474

Closed

samdoran self-assigned this Jun 6, 2019

mkrizek reviewed Jun 6, 2019

View reviewed changes

ansibot added stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. stale_review Updates were made after the last review and the last review is more than 7 days old. labels Jun 7, 2019

samdoran suggested changes Jun 7, 2019

View reviewed changes

samdoran reviewed Jun 7, 2019

View reviewed changes

samccann reviewed Jun 20, 2019

View reviewed changes

ansibot removed the stale_review Updates were made after the last review and the last review is more than 7 days old. label Jun 28, 2019

ansibot added the stale_review Updates were made after the last review and the last review is more than 7 days old. label Jul 6, 2019

ansibot added needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html and removed stale_review Updates were made after the last review and the last review is more than 7 days old. labels Jul 14, 2019

Vladimir-csp mentioned this pull request Jul 19, 2019

Excessive repeated variable resolution during handler notification #59017

Closed

ansibot added the has_issue label Jul 30, 2019

ansibot added pre_azp This PR was last tested before migration to Azure Pipelines. and removed stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. labels Dec 5, 2020

samdoran removed their assignment Jan 7, 2021

ansibot removed the has_issue label Jul 12, 2023

ansibot added needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html and removed needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html labels Oct 24, 2023

ansibot added the stale_pr This PR has not been pushed to for more than one year. label Jan 28, 2025

	By default, if each loop item triggers different notification target, all targets for all items get triggered even if
	By default, if each loop item triggers a different notification target, all targets for all items get triggered even if

Conversation

jtyr commented May 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

SUMMARY

ISSUE TYPE

COMPONENT NAME

ADDITIONAL INFORMATION

Uh oh!

ansibot commented May 22, 2019

Uh oh!

bcoca left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mkrizek commented Jun 6, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

samdoran Jun 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

samccann left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jtyr commented May 22, 2019 •

edited

Loading

samdoran Jun 7, 2019 •

edited

Loading