For debugging purposes during developing playbooks it would make sense
to stop where it breaks rather to print out all the rest each time.
May be with some additional parameter to pass ?
I’m trying to limit the number of parameters we add, so I’m not going to do this.
(We do add parameters for things, but in general, it needs to be for a pretty major use case, like the idea of tagging resources, which we’ll be adding.)
In this case, I would test them on a very small group of hosts, and change the group later to address a larger group of hosts.
Playbooks do stop each host at the first failure, but they are going to report on what hosts fail at each step.
I see another use case for this stopping where it breaks:
When you use -c local, there is only 1 host. In this case, it would be great if ansible-playbook stopped where the error was, and returned a non-zero exit code so that bash -e catches it and also stops any script that may be wrapping ansible-playbook.
That is not an extra param, but extra logic somewhere. Unsure of how much work is involved.
Peter
I see another use case for this stopping where it breaks:
When you use -c local, there is only 1 host. In this case, it would be great if ansible-playbook stopped where the error was, and returned a non-zero exit code so that bash -e catches it and also stops any script that may be wrapping ansible-playbook.
Hmm, well, ansible will already stop each host, so it’s not liking it’s going to plow on for just a few seconds longer to finish it’s output.
There are already folks working on making sure all errors go to stdout, and if someone wants to make sure if any hosts have failures (or unreachable codes) the return code is not zero that is fine, though I do not want extra flags for this particular idea.