Skip to content
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

Closed
willthames opened this issue Aug 24, 2016 · 1 comment
Closed

wrong handler is called when squashed items fail #17208

willthames opened this issue Aug 24, 2016 · 1 comment
Assignees
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
Copy link
Contributor

ISSUE TYPE
  • Bug Report
COMPONENT NAME

handler

ANSIBLE VERSION
ansible 2.2.0 (devel a9322e8b8b) last updated 2016/08/24 14:46:19 (GMT +1000)
  lib/ansible/modules/core: (detached HEAD 368ca738fa) last updated 2016/08/24 15:12:35 (GMT +1000)
  lib/ansible/modules/extras: (detached HEAD 0749ce6faa) last updated 2016/08/24 15:12:35 (GMT +1000)
  config file = 
  configured module search path = Default w/o overrides
CONFIGURATION

N/A

OS / ENVIRONMENT

N/A

SUMMARY

Results of modules with squashed items appear to be misinterpreted.

STEPS TO REPRODUCE
- hosts: localhost
  connection: local
  become: true

  tasks:
  - name: install stuff
    yum:
      name: "{{ item }}"
      state: present
    with_items:
    - bash
    - does-not-exist

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:

$ ansible-playbook yum_fail.yml -K -vv
Using /home/wthames/tmp/ansible/ansible.cfg as config file
SUDO password: 

PLAYBOOK: yum_fail.yml *********************************************************
1 plays in yum_fail.yml

PLAY [localhost] ***************************************************************

TASK [setup] *******************************************************************
Wednesday 24 August 2016  15:22:02 +1000 (0:00:00.030)       0:00:00.030 ****** 
ok: [localhost]

TASK [install stuff] ***********************************************************
task path: /home/wthames/tmp/ansible/yum_fail.yml:8
Wednesday 24 August 2016  15:22:05 +1000 (0:00:03.175)       0:00:03.205 ****** 
failed: [localhost] (item=[u'does-not-exist', u'bash']) => {"changed": false, "failed": true, "item": ["does-not-exist", "bash"], "msg": "No Package matching 'does-not-exist' found available, installed or updated", "rc": 0, "results": []}
    to retry, use: --limit @yum_fail.retry

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1   

Wednesday 24 August 2016  15:22:06 +1000 (0:00:00.910)       0:00:04.116 ****** 
=============================================================================== 
setup ------------------------------------------------------------------- 3.18s
 ------------------------------------------------------------------------------
install stuff ----------------------------------------------------------- 0.91s
/home/wthames/tmp/ansible/yum_fail.yml:8 --------------------------------------
Playbook run took 0 days, 0 hours, 0 minutes, 4 seconds
ACTUAL RESULTS

ok message is displayed in output.

ansible-playbook yum_fail.yml -K -vv
Using /home/wthames/tmp/ansible/ansible.cfg as config file
SUDO password: 

PLAYBOOK: yum_fail.yml *********************************************************
1 plays in yum_fail.yml

PLAY [localhost] ***************************************************************

TASK [setup] *******************************************************************
Wednesday 24 August 2016  15:25:05 +1000 (0:00:00.033)       0:00:00.033 ****** 
ok: [localhost]

TASK [install stuff] ***********************************************************
task path: /home/wthames/tmp/ansible/yum_fail.yml:6
Wednesday 24 August 2016  15:25:08 +1000 (0:00:03.253)       0:00:03.287 ****** 
ok: [localhost] => (item=[u'bash', u'does-not-exist']) => {"changed": false, "failed": true, "item": ["bash", "does-not-exist"], "msg": "No Package matching 'does-not-exist' found available, installed or updated", "rc": 0, "results": ["bash-4.3.42-3.fc23.x86_64 providing bash is already installed"]}
    to retry, use: --limit @yum_fail.retry

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1   

Wednesday 24 August 2016  15:25:09 +1000 (0:00:00.935)       0:00:04.222 ****** 
=============================================================================== 
setup ------------------------------------------------------------------- 3.25s
 ------------------------------------------------------------------------------
install stuff ----------------------------------------------------------- 0.94s
/home/wthames/tmp/ansible/yum_fail.yml:6 --------------------------------------
Playbook run took 0 days, 0 hours, 0 minutes, 4 seconds
@nitzmahone nitzmahone added bug_report P2 Priority 2 - Issue Blocks Release labels Aug 25, 2016
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
@ansibot ansibot added triage affects_2.2 This issue/PR affects Ansible v2.2 labels Sep 7, 2016
@jimi-c jimi-c self-assigned this Sep 23, 2016
@jimi-c jimi-c modified the milestone: 2.2.0 Sep 27, 2016
@bcoca bcoca removed the triage label Sep 27, 2016
@mckerrj mckerrj modified the milestones: 2.3.0, 2.2.0 Sep 30, 2016
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)
@abadger
Copy link
Contributor

abadger commented Oct 25, 2016

Tested and dag's fix does indeed fix this:

TASK [install stuff] ***********************************************************
failed: [localhost] (item=[u'bash', u'does-not-exist']) => {"changed": false, "failed": true, "item": ["bash", "does-not-exist"], "msg": "No package matching 'does-not-exist' found available, installed or updated", "rc": 126, "results": ["bash-4.3.43-4.fc25.x86_64 providing bash is already installed", "No package matching 'does-not-exist' found available, installed or updated"]}
        to retry, use: --limit @/srv/ansible/troubleshooting/17208.retry

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1 

Closing fixed in 2.2.0

@abadger abadger closed this as completed Oct 25, 2016
@abadger abadger modified the milestones: 2.2.0, 2.3.0 Oct 25, 2016
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
@ansibot ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 7, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants