# making module responses available to handlers / only\_if for handlers

**URL:** <https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393>\
**Category:** Ansible Project\
**Created:** [April 4, 2012, 8:10pm UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393 "2012-04-04T20:10:43Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Matthew\_Williams](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Matthew\_Williams](https://forum.ansible.com/u/Matthew_Williams)\
**Post date:** [April 4, 2012, 8:10pm UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/1 "2012-04-04T20:10:43Z")

</div>

```auto
Sometimes it is desirable to perform a handle on some other event than 'changed'. Any opinions on the following possible playbook syntax?

```

```auto

```

```auto
- name: pull / update some repo
  action: git repos=foo dest=bar version=1.3
  notify: 
  - handler: foo-new
    only_if: action_response['changed'] # << this is the default, when only_if is not defined
  - handler: foo-update
    only_if: action_response['version-changed'] and foo = bar # << mix in some other logic

```

```auto

```

```auto
Existing syntax would continue to be compatible. If this syntax were adopted notify could take a string (a single handler to execute on change), a dictionary (a single handler with an only_if option), or a list of strings and/or handlers.

```

```auto

```

```auto
Thoughts?

```

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 4, 2012, 8:16pm UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/2 "2012-04-04T20:16:09Z")

</div>

So git is only going to return a changed if the contents change, so that seems like version-changed wouldn’t exist.

---

<div class="post-metadata">

**Author:** ![Matthew\_Williams](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Matthew\_Williams](https://forum.ansible.com/u/Matthew_Williams)\
**Post date:** [April 4, 2012, 8:37pm UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/3 "2012-04-04T20:37:48Z")

</div>

OK, so 'changed' would be any change -- new clone, pull with updates,  
or version= caused a change. In other words, something on the FS  
changed, just as now.

Let's use 'new-clone' as an example instead of 'version-changed'.  
new-clone would only be True if clone was used rather than pull...

---

<div class="post-metadata">

**Author:** ![Matthew\_Williams](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Matthew\_Williams](https://forum.ansible.com/u/Matthew_Williams)\
**Post date:** [April 4, 2012, 8:38pm UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/4 "2012-04-04T20:38:26Z")

</div>

Also... My thought was that all matching handlers would be triggered,  
not just the first to match. Not sure if that was clear.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 4, 2012, 8:40pm UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/5 "2012-04-04T20:40:17Z")

</div>

> OK, so ‘changed’ would be any change – new clone, pull with updates,  
> or version= caused a change. In other words, something on the FS  
> changed, just as now.
> 
> Let’s use ‘new-clone’ as an example instead of ‘version-changed’.  
> new-clone would only be True if clone was used rather than pull…

what’s the real world example of your setup that should only be run on an update not an initial install?

there may be other solutions and the end goal should be to make things reasonably idempotent, so there  
might be another solution

hard to say without seeing a real-world playbook excerpt, sans ‘foo’

---

<div class="post-metadata">

**Author:** ![Matthew\_Williams](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Matthew\_Williams](https://forum.ansible.com/u/Matthew_Williams)\
**Post date:** [April 5, 2012, 12:37am UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/6 "2012-04-05T00:37:17Z")

</div>

The real world example is actually the other way around. In my case,  
it has to do with a setup script that should be run if git does a  
clone (new install) but not if it does a pull. Now that I think about  
it, though, the way I'm doing it is better... check whether a file  
that the setup creates exists. While it might be 'cleaner' to do it  
with an only\_if statement, it could cause unpredictable results if,  
for example, the former run of the playbook had failed after cloning  
but before running setup.

I'll let you know if I encounter another situation where this might be  
handy. Until then, I won't mention it further.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 5, 2012, 1:17am UTC](https://forum.ansible.com/t/making-module-responses-available-to-handlers-only-if-for-handlers/11393/7 "2012-04-05T01:17:03Z")

</div>

Offhand, this sounds like an excellent case for RPM packaging vs using the git module, where the difference between an install and upgrade is detectable, and the package can handle the post scriptlets.

I’m not sure about dpkg but would presume it can do similar.

–Michael