-
Notifications
You must be signed in to change notification settings - Fork 23.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blocks: rescue or always not run when error comes from a run_once task #16937
Comments
Might also be somewhat related to #16050. |
I can confirm this bug. It does not happen on v2.1.0.0-1, but everything later does not work correctly. I have narrowed it down to fbec2d9 linear.py lines 364 and 365. Reverting this part of that patch will fix this but, but I think will also undo the fix for #16937. A real fix for both of these issues is to not treat run_once as any_error_fatal, and have a different logic path if it fails. This would mark all of the hosts in that play as failed, and then run the appropriate recovery logic. |
cc @jimi-c |
Instead of immediately returning a failed code (indicating a break in the play execution), we internally 'or' that failure code with the result (now an integer flag instead of a boolean) so that we can properly handle the rescue/always portions of blocks and still remember that the break condition was hit. Fixes #16937
@Gugli / @MadVikingGod the above branch is a first attempt at fixing this. Still needs some work but I think the basics are there. I still need to:
|
Hrm, and it looks like I've got some other bit of logic wrong.. this test succeeded but there was a non-zero exit code: https://app.shippable.com/runs/57a4dfa5d640fc0d00f90f97/5/console |
$ ansible -m ping localhost localhost | SUCCESS => { "changed": false, "ping": "pong" } $ echo $? 1 |
In the linear strategy the flag run_once was synomious with any_error_fatal for error checking. This caused plays to abort before running any rescue or always blocks. By remove this the play executes as expected, and the error handeling is handled by the executor. This is a fix for ansible#16937
Instead of immediately returning a failed code (indicating a break in the play execution), we internally 'or' that failure code with the result (now an integer flag instead of a boolean) so that we can properly handle the rescue/always portions of blocks and still remember that the break condition was hit. Fixes #16937
I hit this today on |
Instead of immediately returning a failed code (indicating a break in the play execution), we internally 'or' that failure code with the result (now an integer flag instead of a boolean) so that we can properly handle the rescue/always portions of blocks and still remember that the break condition was hit. Fixes #16937
The branch above is working and passing tests, if anyone else would like to give it a test before I merge it into devel. |
Closing This TicketHi! We believe the above commit should resolve this problem for you. This will also be included in the next release. If you continue seeing any problems related to this issue, or if you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:
Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved. Thank you! |
1 similar comment
Closing This TicketHi! We believe the above commit should resolve this problem for you. This will also be included in the next release. If you continue seeing any problems related to this issue, or if you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:
Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved. Thank you! |
ISSUE TYPE
ANSIBLE VERSION
CONFIGURATION
Out of the box config on Ubuntu14
OS / ENVIRONMENT
Ansible runs on Ubuntu14, targeted machines on Ubuntu16.
SUMMARY
Using
run_once
on a task inside a block preventsrescue
andalways
sections to be correctly triggered.STEPS TO REPRODUCE
Run this playbook on any inventory file. This is basically the sample from the official documentation with just a
run_once
addedEXPECTED RESULTS
I was expecting
ACTUAL RESULTS
Related issues
This might be related to #16254, but the steps to reproduce are so different I though it best to make a new Issue report.
The text was updated successfully, but these errors were encountered: