# Playbook: can actions be grouped to trigger a single notification? **URL:** \ **Category:** Ansible Project\ **Created:** [July 11, 2012, 11:43am UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662 "2012-07-11T11:43:39Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jpmens1](https://avatars.discourse-cdn.com/v4/letter/j/e9c0ed/32.png) [@jpmens1](https://forum.ansible.com/u/jpmens1)\ **Post date:** [July 11, 2012, 11:43am UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662/1 "2012-07-11T11:43:39Z")
I'd like to be able to group actions in a playbook thusly, so as to specify a single notification only: ---
**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:** [July 11, 2012, 12:25pm UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662/2 "2012-07-11T12:25:48Z")
> I'd like to be able to group actions in a playbook thusly, so as to > specify a single notification only: > > --- > - hosts: xxx > tasks: > - action: copy src=... > - action: template src=... > - action: copy src=... > notify: > - restart sshd > > handlers: > - name: restart sshd > action: service name=sshd state=restarted > > In other words, irrespective which of the three tasks changed something, > I'd like the notify handler triggered. Is that possible? (Above example > triggers the notify only for the third action.) Add the notify handler to each task and you'll be fine. It will trigger only once. > BTW: [1] stipulates "Every task MUST have a name, which is included in > the output from running the playbook." (emphasis mine). That's not quite > true (see example above). That's not true, tasks don't need a name. It's a documentation excerpt from a previous version of the app that needs fixing. However, it's definitely a good practice to always give them a name to document what you are doing and why, as these names show up when running play books instead of the raw ansible commands, so it can make things a lot more readable. ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [July 11, 2012, 8:36pm UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662/3 "2012-07-11T20:36:33Z")
I am not convinced. Most of the actions are very basic and self-explanatory. If you want to document something, it's most probably why we are doing it rather than what is done. What's more, since I have so many actions, and so many systems, outputting for each play, each action and each system one line (both on success and failure) is not very practical. And for that reason I think we will have to evolve to a more unix-style output mechanism.   - by default, only output when something fails, and in this case print     also the system, playbook, play and action that failed   - when made verbose, show more information about failures   - when made more verbose, show all the success too Same for logging, the current log contains every single action on every system which is not very useful. I'd like to see less logged, only actions that change something and maybe start (and end ?). And somehow I think it would be useful to have a dry-run option, which depending on the module would check more than some others, e.g. copy could only do the md5 comparison. And my personal preference would be to also have a diff output/logging option where it would not just execute actions, but also make diffs for files that have been changed, or other actions that are taken. Of course this would require quite some changes to the modules, but it makes Ansible runs auditable in practice \_and\_ there might be a possibility to revert changes based on diffs/actions. PS The above functionality is what I am used to from my own custom provisioning and retrofitting system. Over-and-out 😉 ---
**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:** [July 11, 2012, 8:52pm UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662/4 "2012-07-11T20:52:13Z")
> > However, it’s definitely a good practice to always give them a name to > > document what you are doing and why, as these names show up when running > > play books instead of the raw ansible commands, so it can make things a > > lot more readable. > > I am not convinced. Most of the actions are very basic and > self-explanatory. If you want to document something, it’s most probably > why we are doing it rather than what is done. They are optional, so you don’t have to use them. > > - by default, only output when something fails, and in this case print > also the system, playbook, play and action that failed This is the proposal for a “–quiet”. I’m not against it. > - when made verbose, show more information about failures > > - when made more verbose, show all the success too This is kind of what we already have now, in that verbose mode shows you info even if something succeeds. I agree different people want different things. I will address some other points in a later, more generalized, not specifically in reply to this one, email 🙂 ---
**Author:** ![jpmens1](https://avatars.discourse-cdn.com/v4/letter/j/e9c0ed/32.png) [@jpmens1](https://forum.ansible.com/u/jpmens1)\ **Post date:** [July 11, 2012, 9:03pm UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662/5 "2012-07-11T21:03:39Z")
> \> tasks: > \> - action: copy src=... > \> - action: template src=... > \> - action: copy src=... > \> notify: > \> - restart sshd > Add the notify handler to each task and you'll be fine. I know, but it's tedious and repetitive. My example above example demonstrates what I'd like: each of the three actions (if they change something) are going to trigger the notification. > It will trigger only once. I understand that, and it works as you say. > That's not true, tasks don't need a name [...] > However, it's definitely a good practice to always give them a name to > document what you are doing and why, as these names show up when > running play books instead of the raw ansible commands, so it can make > things a lot more readable. I disagree: output is too verbose as it is and difficult to read and to parse. A great improvement, if possible, would be that at the end of the playbook run, I'm shown which action (name/task) failed on which host.         -JP ---
**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:** [July 11, 2012, 9:40pm UTC](https://forum.ansible.com/t/playbook-can-actions-be-grouped-to-trigger-a-single-notification/11662/6 "2012-07-11T21:40:36Z")
> I disagree: output is too verbose as it is and difficult to read and to > parse. A great improvement, if possible, would be that at the end of the > playbook run, I’m shown which action (name/task) failed on which host. This seems to be the argument for --quiet again, to hide the various “ok” steps. I still find this useful when running against a large host pool and knowing how far in we are, so it might need to print “.” or something in quiet mode. Not opposed to patches for hiding some of this, but it should print things when they actually fail, as it does now, but just hide the OKs and probably the task headers. Callbacks mechanism is pretty simple, see callbacks.py I am not going to change the order of when things are printed, you do get the host summary at the bottom which shows the failure counts and then if you used –quiet as you say you could just scroll up a bit. –Michael