Feature RFC: allow task failures to trigger non-zero exit codes

The new command line option is not something I want.

Why not just return non-zero if any host has failures?

Both ansible and ansible-playbook should be included, and it shouldn't
require any changes to the core.

Michael,

Thanks for the feedback. I thought the flexibility of specifying the number of host failures would be helpful/necessary for some scenarios. E.g. I could imagine an administrator that desires a non-zero exit if, any only if all hosts had failures. Does this make sense?

As for not making any changes to core – I imagine that I’ve done this by modifying bin/ansible-playbook and am at a loss as to how to accomplish this without modifying this (or the bin/ansible) file. Can you point me in the right direction?

~ Brice

Michael,

Thanks for the feedback. I thought the flexibility of specifying the number
of host failures would be helpful/necessary for some scenarios. E.g. I could
imagine an administrator that desires a non-zero exit if, any only if all
hosts had failures. Does this make sense?

Not really.

As for not making any changes to core -- I imagine that I've done this by
modifying bin/ansible-playbook and am at a loss as to how to accomplish this
without modifying this (or the bin/ansible) file. Can you point me in the
right direction?

You misread.

Modify /bin/ansible, and /bin/ansible-playbook, do NOT modify the source code.

In other words, no new command line parameters, just iterate over the results.

Ack forgot to answer…

Wouldn't this potentially break backwards compatibility? I imagine some
production scripts pre this merge will now exit 1 vs. 0.

No, if anything, it's a bugfix.

Michael,

Got it. I think I’ll maintain my patch – as the above is such a trivial modification && doesn’t provide the flexibility we’ll eventually need. If you want me to submit a pull request I will.

Having ‘all’ in the command line option will become necessary for us in the future when we start dealing with multiple (100s) of webservers. I imagine a task failing on one or two of them for some reason or another [such as failed provisioning or unresponsiveness], but not on all. All would indicate a problem with the playbook / task itself.

The command line option also doesn’t break backwards compat which I wouldn’t want to be responsible for :wink:

~ Brice

I strongly disagree that this is a "break".

I do agree that your use case is a little weird, and probably should
be it's own API script.