ansible-playbook aborts run without proper notice when all hosts in one play fail even when plays for not-failed hosts are left

[henkworks]

Did not find any already existing issue.

I did not test any other versions.

SUMMARY

ansible-playbook run stops unexpectedly and without notice when it should continue.

ISSUE TYPE

• Documentation Report
• ~Bug Report~

COMPONENT NAME

core?

ANSIBLE VERSION

ansible 2.9.13
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/henk/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0]

CONFIGURATION

ANSIBLE_NOCOWS(env: ANSIBLE_NOCOWS) = True

OS / ENVIRONMENT

Debian stable (with backports for e.g. ansible) I don’t think much else is relevant to this issue but feel free to ask.

STEPS TO REPRODUCE

ansible-playbook -DC -i 'henk@127.0.0.1,henk@127.0.1.1' play-abort-test.yaml

- name: "play 1"
  hosts: "127.0.0.1"
  tasks:
    - fail:
- name: "play 2"
  hosts: "127.0.1.1"
  tasks:
    - debug: msg="hi"

EXPECTED RESULTS

I would expect it to continue with "play 2" because it’s a different host that has not failed any play yet and I did not tell ansible to stop on any error.

ACTUAL RESULTS

ansible stops after "play 1" without saying why, does not even mention the second host in the stats.

PLAY [play 1] ******************************************************************************************************************************************************************************************************

TASK [Gathering Facts] *********************************************************************************************************************************************************************************************
ok: [127.0.0.1]

TASK [fail] ********************************************************************************************************************************************************************************************************
fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "Failed as requested from task"}

PLAY RECAP *********************************************************************************************************************************************************************************************************
127.0.0.1                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

[1]    10467 exit 2     ansible-playbook -DC -i 'henk@127.0.0.1,henk@127.0.1.1' play-abort-test.yaml

[ansibot]

Files identified in the description: None

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[sivel]

This is expected. If a play completely fails, then the playbook aborts. This follows the expected behavior of Ansible where a playbook will fail fast.

We should probably expand the documentation here to explain this in more depth.

[lucasbasquerotto]

Should the playbook fail and next plays don't run even if they are unrelated to the play that returned with errors?

For example, you run the 1st play that create prometheus, elasticsearch and wordpress nodes, then run some setup code in the prometheus nodes in the 2nd play, and in the 3rd and 4th you run the setup in the elasticsearch and wordpress nodes, respectively.

Should the code that run in the elasticsearch and wordpress nodes stop running even if only the prometheus hosts failed, and are unrelated to the other nodes (after the 1st play)?

[ansibot]

Thank you very much for your submission to Ansible. It means a lot to us that you've taken time to contribute.

Unfortunately, this issue has been open for some time while waiting for a contributor to take it up but there does not seem to have been anyone that did so. So we are going to close this issue to clear up the queues and make it easier for contributors to browse possible implementation targets.

However, we're absolutely always up for discussion. Because this project is very active, we're unlikely to see comments made on closed tickets and we lock them after some time. If you or anyone else has any further questions, please let us know by using any of the communication methods listed in the page below:

• https://docs.ansible.com/ansible/latest/community/communication.html

In the future, sometimes starting a discussion on the development list prior to proposing or implementing a feature can make getting things included a little easier, but it's not always necessary.

Thank you once again for this and your interest in Ansible!

click here for bot help