I'd like to be able to group actions in a playbook thusly, so as to
specify a single notification only:
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 sshdhandlers:
- name: restart sshd
action: service name=sshd state=restartedIn 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.
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 
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 
> 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
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