-
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
wrong handler is called when squashed items fail #17208
Labels
affects_2.2
This issue/PR affects Ansible v2.2
bug
This issue/PR relates to a bug.
P2
Priority 2 - Issue Blocks Release
Milestone
Comments
willthames
added a commit
to willthames/ansible
that referenced
this issue
Aug 26, 2016
The results field in a task result is not necessarily a list of dicts containing `failed` and `changed` keys, but can just be a list of strings (e.g. the results from the yum module). In that case, the results list is not useful for calculating `changed` or `failed`, at which point `_check_key` should fail back to the `changed` or `failed` key in the task result itself e.g. the result from yum looks a little like: ``` self._result = { 'failed': true, 'results': ['a already installed', 'b already installed', 'could not install c'] } ``` and the result should be the `failed` key, and not the fact that none of the results contained a `failed` key. Fixes ansible#17208
dagwieers
added a commit
to dagwieers/ansible-modules-core
that referenced
this issue
Sep 5, 2016
The implementation is fairly simple, we force the rc= parameter to not be zero so that the check in _executor/task_result.py_ correctly determines that it failed. Without this change Ansible would report the task to be ok (despite failed=True and msg=Some_error_message) although Ansible stops and the summary output reports a failed task. This fixes ansible#4214, ansible#4384 and also relates to ansible/ansible#12070, ansible/ansible#16006, ansible/ansible##16597, ansible/ansible#17208 and ansible/ansible#17252
dagwieers
added a commit
to dagwieers/ansible-modules-core
that referenced
this issue
Sep 5, 2016
The implementation is fairly simple, we force the rc= parameter to not be zero so that the check in _executor/task_result.py_ correctly determines that it failed. Without this change Ansible would report the task to be ok (despite failed=True and msg=Some_error_message) although Ansible stops and the summary output reports a failed task. This fixes ansible#4214, ansible#4384 and also relates to ansible/ansible#12070, ansible/ansible#16006, ansible/ansible##16597, ansible/ansible#17208 and ansible/ansible#17252
abadger
pushed a commit
to ansible/ansible-modules-core
that referenced
this issue
Oct 18, 2016
The implementation is fairly simple, we force the rc= parameter to not be zero so that the check in _executor/task_result.py_ correctly determines that it failed. Without this change Ansible would report the task to be ok (despite failed=True and msg=Some_error_message) although Ansible stops and the summary output reports a failed task. This fixes #4214, #4384 and also relates to ansible/ansible#12070, ansible/ansible#16006, ansible/ansible##16597, ansible/ansible#17208 and ansible/ansible#17252
abadger
pushed a commit
to ansible/ansible-modules-core
that referenced
this issue
Oct 18, 2016
The implementation is fairly simple, we force the rc= parameter to not be zero so that the check in _executor/task_result.py_ correctly determines that it failed. Without this change Ansible would report the task to be ok (despite failed=True and msg=Some_error_message) although Ansible stops and the summary output reports a failed task. This fixes #4214, #4384 and also relates to ansible/ansible#12070, ansible/ansible#16006, ansible/ansible##16597, ansible/ansible#17208 and ansible/ansible#17252 (cherry picked from commit 20726b9)
Tested and dag's fix does indeed fix this:
Closing fixed in 2.2.0 |
bdowling
pushed a commit
to bdowling/ansible-modules-core
that referenced
this issue
Oct 28, 2016
The implementation is fairly simple, we force the rc= parameter to not be zero so that the check in _executor/task_result.py_ correctly determines that it failed. Without this change Ansible would report the task to be ok (despite failed=True and msg=Some_error_message) although Ansible stops and the summary output reports a failed task. This fixes ansible#4214, ansible#4384 and also relates to ansible/ansible#12070, ansible/ansible#16006, ansible/ansible##16597, ansible/ansible#17208 and ansible/ansible#17252
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
affects_2.2
This issue/PR affects Ansible v2.2
bug
This issue/PR relates to a bug.
P2
Priority 2 - Issue Blocks Release
ISSUE TYPE
COMPONENT NAME
handler
ANSIBLE VERSION
CONFIGURATION
N/A
OS / ENVIRONMENT
N/A
SUMMARY
Results of modules with squashed items appear to be misinterpreted.
STEPS TO REPRODUCE
Note that if you swap bash and does-not-exist around, it works as expected. Basically, because results array is populated by each successful installation, the behaviour is different when it fails on the first item vs the second item.
This is similar to #16766 in that the result of is_failed is incorrect, but for a different reason. I raise this as an issue rather than a PR as I'm not sure what the results should be.
One might argue that this should be an against yum rather than core - but the results of the yum task look reasonable in the absence of documentation that explicitly sets out conditions for module failues, and it seems to be the parsing of the results from yum that is at fault rather than yum module itself.
EXPECTED RESULTS
failure message is displayed in output as when does-not-exist is first item in list:
ACTUAL RESULTS
ok message is displayed in output.
The text was updated successfully, but these errors were encountered: