Last update (I think).
So i managed to clarify the situation. Seems that the problem occurs only
when i'm using roles with block/rescue options. Without it everything works
smooth.
For example:
*Roles Playbook without block/rescue:- hosts: TEONET01A,TEONET01B*
* gather_facts: false any_errors_fatal: True roles: - test Roles task
(block commented): --- # - name: Run test pbook # block: - assert: that: -
ansible_hostname == 'TEONET01A' - debug: msg: In role # rescue: # - debug:
# msg: Rescue Runs as expected and play exists after fatal error in
assert:root@PCEDVKAIL3:/etc/ansible# ansible-playbook playbook.ymlPLAY
[TEONET01A,TEONET01B]
***************************************************************************************************************************************************************************************************************************************************************
TASK [test : assert]
*********************************************************************************************************************************************************************************************************************************************************************
[WARNING]: ansible-pylibssh not installed, falling back to paramiko ok:
[10.8.250.46] => { "changed": false, "msg": "All assertions passed" }
[WARNING]: ansible-pylibssh not installed, falling back to paramiko fatal:
[10.8.250.47]: FAILED! => { "assertion": "ansible_hostname == 'TEONET01A'",
"changed": false, "evaluated_to": false, "msg": "Assertion failed" } NO
MORE HOSTS LEFT
***********************************************************************************************************************************************************************************************************************************************************************
PLAY RECAP
*******************************************************************************************************************************************************************************************************************************************************************************
10.8.250.46 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0
ignored=0 10.8.250.47 : ok=0 changed=0 unreachable=0 failed=1 skipped=0
rescued=0 ignored=0 Now how it works with block/rescue - seems like bugsame
playbook:- hosts: TEONET01A,TEONET01B gather_facts: false any_errors_fatal:
True roles: - test Roles (block uncommented): --- - name: Run test pbook
block: - assert: that: - ansible_hostname == 'TEONET01A' - debug: msg: In
role rescue: - debug: msg: Rescue Runs as not expected and play continues
with other host even the host assert fails: root@PCEDVKAIL3:/etc/ansible#
ansible-playbook playbook.yml PLAY [TEONET01A,TEONET01B]
***************************************************************************************************************************************************************************************************************************************************************
TASK [test : assert]
*********************************************************************************************************************************************************************************************************************************************************************
[WARNING]: ansible-pylibssh not installed, falling back to paramiko ok:
[10.8.250.46] => { "changed": false, "msg": "All assertions passed" }
[WARNING]: ansible-pylibssh not installed, falling back to paramiko fatal:
[10.8.250.47]: FAILED! => { "assertion": "ansible_hostname == 'TEONET01A'",
"changed": false, "evaluated_to": false, "msg": "Assertion failed" } TASK
[test : debug]
**********************************************************************************************************************************************************************************************************************************************************************
ok: [10.8.250.46] => { "msg": "In role" } TASK [test : debug]
**********************************************************************************************************************************************************************************************************************************************************************
ok: [10.8.250.47] => { "msg": "Rescue" } PLAY RECAP
*******************************************************************************************************************************************************************************************************************************************************************************
10.8.250.46 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0
ignored=0 10.8.250.47 : ok=1 changed=0 unreachable=0 failed=0 skipped=0
rescued=1 ignored=0 *
On Tue, Jun 6, 2023 at 4:29 PM Edvinas Kairys <[email protected]>
wrote:
> checked again, problem with serial 1 is that it doesn't run tasks in
> parallel.
>
> so then i have same playbook which is not in roles it runs like this:
>
>
>
>
> *TASK [assert]
> **********************************************************************************************************ok:
> [10.8.250.46]fatal: [10.8.250.47]: FAILED! => {"assertion": "('MGMT0' not
> in interface_running_config['interface']['Ethernet' ~
> full_fex_interface_number]['description'] | default (''))", "changed":
> false, "evaluated_to": false, "msg": "failed"}[10.8.250.47] TASK: assert
> (debug)>*
>
> but when the same playbook is in roles modes it continues to play even
> assert fails:
>
>
>
>
>
>
> *TASK [network_port_channel : assert]
> ******************************************************************************************************************************************************************************fatal:
> [TEONET01B]: FAILED! => {"assertion": "('MGMT0' not in
> interface_running_config['interface']['Ethernet' ~
> full_fex_interface_number]['description'] | default (''))", "changed":
> false, "evaluated_to": false, "msg": "failed"}ok: [TEONET01A]TASK
> [network_port_channel : fail]
> ********************************************************************************************************************************************************************************skipping:
> [TEONET01A]*
>
> So i still think that it's the bug - the any_errors_fatal: true doenst
> work in roles.
>
> Will, i think this sentence ("Ansible *finishes the fatal task on all
> hosts in the current batch*"). Means that it finishes only the TASK but
> not the whole playbook.
>
>
>
>
> On Tue, Jun 6, 2023 at 1:07 PM Edvinas Kairys <[email protected]>
> wrote:
>
>> I havent mentioned, that im using roles, when thereis simple playbook -
>> everything works as expected - it quits playbook after assertion fails.
>> When using roles - the assertion fails - and the playbook continues only
>> with the host, which had assertion passed.
>>
>> I think its a bug, but i will try serial 1.
>>
>> On Tuesday, June 6, 2023, Will McDonald <[email protected]> wrote:
>>
>>> Hey Edvinas,
>>>
>>> As Kosala mentions, this should do what you want, however I think the
>>> specific piece of documentation to note is "Ansible *finishes the fatal
>>> task on all hosts in the current batch*". With 2 hosts, and the default
>>> of 5 forks, your batch size will be 5 so your play will carry on across
>>> both hosts. If you set "serial: 1" it'll probably behave the way you want.
>>>
>>> Cheers,
>>>
>>> Will.
>>>
>>> On Tue, 6 Jun 2023 at 08:05, "Kosala Atapattu (කෝසල අතපත්තු)" <
>>> [email protected]> wrote:
>>>
>>>> The doc says it should do what you’re after.
>>>>
>>>> If you set any_errors_fatal and a task returns an error, Ansible
>>>> finishes the fatal task on all hosts in the current batch, then stops
>>>> executing the play on all hosts. Subsequent tasks and plays are not
>>>> executed. You can recover from fatal errors by adding a rescue section
>>>> <https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_blocks.html#block-error-handling>
>>>> to
>>>> the block. You can set any_errors_fatal at the play or block level.
>>>>
>>>>
>>>> I never have used it personally, but are you setting
>>>> any_errors_fatal:true at the task level or playbook level?
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 6/06/2023, at 6:51 PM, Edvinas Kairys <[email protected]>
>>>> wrote:
>>>>
>>>> Hello, thanks for reply.
>>>>
>>>> I've two hosts in the play, and one of the hosts assert module doesnt
>>>> validate to true and fails. With any_errors_fatal command I expect the
>>>> playbook to stop on all hosts within the play. But in my case, the play
>>>> stops only on failed host, it continues with other host where assertions
>>>> passed.
>>>>
>>>> Is this expected behaviour ?
>>>>
>>>> On Tuesday, June 6, 2023, Kosala Atapattu <[email protected]>
>>>> wrote:
>>>>
>>>>> Yes any_errors_fatal is what you need:
>>>>> https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_error_handling.html#aborting-on-the-first-error-any-errors-fatal
>>>>>
>>>>> When you say it doesn't seem to work, what does not seem to work?
>>>>>
>>>>> *Kosala*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 6, 2023 at 2:07 AM [email protected] <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> My playbook has several hosts, and I have some tasks with *assert *and
>>>>>> *fail *modules. How to do that if the task gets any fatal error in
>>>>>> the play within particular host - the whole play should is terminated ?
>>>>>>
>>>>>> I thought that playbook command *any_errors_fatal *would work, but
>>>>>> seems not.
>>>>>>
>>>>>> Is there any other way to make playbook stop if any of the hosts
>>>>>> experiences errors ?
>>>>>>
>>>>>> I see ansible has meta modules - there are some kind like end_play
>>>>>> module, maybe this one would work..
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Ansible Project" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/ansible-project/87c9f759-872f-40b7-b80c-73f61817fb82n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/ansible-project/87c9f759-872f-40b7-b80c-73f61817fb82n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "Ansible Project" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/ansible-project/VjdgAcJWJzc/unsubscribe
>>>>> .
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> [email protected].
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/ansible-project/CAP7S5HawfBqkb4L1DjmZumHmJFw-Rtm8Fuh4t2JCuKmr_AE_-A%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/ansible-project/CAP7S5HawfBqkb4L1DjmZumHmJFw-Rtm8Fuh4t2JCuKmr_AE_-A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Ansible Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ansible-project/CAOrc2M9XhNiSe5ieGYMoonMU0gnScrp1fUv2YtzZdm4gy8sW_g%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/ansible-project/CAOrc2M9XhNiSe5ieGYMoonMU0gnScrp1fUv2YtzZdm4gy8sW_g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Ansible Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ansible-project/66611F66-7964-4D3F-8CB8-2018FEBAB763%40gmail.com
>>>> <https://groups.google.com/d/msgid/ansible-project/66611F66-7964-4D3F-8CB8-2018FEBAB763%40gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Ansible Project" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/ansible-project/VjdgAcJWJzc/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ansible-project/CAKtKohQtv40%2BsXbpkfhQwJwZC%3DDS2RyjtFj12_gz1QDfZFWTag%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/ansible-project/CAKtKohQtv40%2BsXbpkfhQwJwZC%3DDS2RyjtFj12_gz1QDfZFWTag%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAOrc2M_6ffu%3DSTpqpC2DQe%2B%2BDVR0NW6J3JhxX45iu%3DaDDiCAmw%40mail.gmail.com.
