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

Add "break_when" to the "loop_control" #51881

Closed
taraspos opened this issue Feb 7, 2019 · 6 comments
Closed

Add "break_when" to the "loop_control" #51881

taraspos opened this issue Feb 7, 2019 · 6 comments
Labels
affects_2.8 This issue/PR affects Ansible v2.8 bot_closed feature This issue/PR relates to a feature request. support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@taraspos
Copy link

taraspos commented Feb 7, 2019

SUMMARY

Add the ability to break the loop conditionally.

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

core

ADDITIONAL INFORMATION
- set_fact:
       array: ["1", "2", "3", "stop here", "33333333" ]

- debug:
      var: item
   loop: "{{ array }}"
   loop_control:
       break_when: '{{ item }} == "stop here"'
@ansibot ansibot added affects_2.8 This issue/PR affects Ansible v2.8 feature This issue/PR relates to a feature request. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Feb 7, 2019
@s-hertel s-hertel removed the needs_triage Needs a first human triage before being processed. label Feb 12, 2019
@samdoran
Copy link
Contributor

This could be added to the proposals on improving loops:

@bcoca
Copy link
Member

bcoca commented Mar 4, 2019

you already can 'kindof' do this via existing when:, using the registered var and previous item state

@jgibart
Copy link

jgibart commented Feb 19, 2020

It is currently very hard to have error control on tasks in loop.
You can not stop loop until end even when a task in the loop is in error

I dont see how you can do what the previous comment suggesst :
You may access the previous item state and skip item after the failed one , but what about the other items after ?

I'm trying to implement a script to perform rolling restart or clustered services.
The idea is to restart services one by one but to stop immediately when a service fails, so that we dont shutdown another healthy server in case the new binary doesnt work.

The "intelligence" of starting and declaring the service up or down is delegated to a script. Basically this script attempts to start a systemd service and then run a sanity test just after. In case of failure it fails ( exits 1).

In order to serialize just the servers restart I used an pattern in a delegating loop

- name: "ensure service '{{service}}'  started (run task host by host) "
  become: yes
  become_method: sudo
  script:  "secure_start.py  --service {{ service }}   --state {{ 'restarted' if   binary.changed   else 'started' }}"
  when: hostitem in deployments[service] 
  delegate_to: "{{ hostitem }}"
  register: testout
  changed_when: "testout.stdout | from_json|json_query('changed')"
  with_items: "{{ groups['applicative'] }}"
  loop_control:
    loop_var: hostitem
  run_once: true

The problem with this pattern is that if restart on host 1 fails the restart is still attempted on host 2
and only when the loop is complete the task is marked failed.

I'd like the loop to stop at first error.

Is it possible to implement a break_when condition to stop loop ? Here for example :
break_when: testout.failed

I didnt find an easy workaround for this issue.

Thank you.

@bcoca
Copy link
Member

bcoca commented Jan 8, 2021

mostly implemented in #62151

@bcoca
Copy link
Member

bcoca commented Feb 16, 2022

waiting_on_contributor

@ansibot ansibot added the waiting_on_contributor This would be accepted but there are no plans to actively work on it. label May 6, 2022
@ansibot
Copy link
Contributor

ansibot commented May 9, 2023

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:

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

@ansibot ansibot added bot_closed and removed waiting_on_contributor This would be accepted but there are no plans to actively work on it. labels May 9, 2023
@ansibot ansibot closed this as completed May 9, 2023
@ansible ansible locked and limited conversation to collaborators May 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.8 This issue/PR affects Ansible v2.8 bot_closed feature This issue/PR relates to a feature request. support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

No branches or pull requests

6 participants