strings templated using a lookup in a loop shouldn't be cached and re-used about ansible HOT 8 OPEN

@qiwangrh I reclassified this as a feature (we can't change the behavior without breaking content since it is working as designed), but how different keywords interact with different stages of task execution is definitely something we need to document better. There's an open issue for that here: ansible/ansible-documentation#1295.

I just merged a loop_control break_when feature for 2.18 (#62151) that can be used like this:

- ansible.builtin.set_fact:
    deployment_engine_ip: "{{ lookup('community.general.dig', deployment_engine_fqdn) }}"
  loop: "{{ range(0, 60) }}"
  loop_control:
    pause: 12
    break_when: deployment_engine_ip != initial_deployment_engine_ip

Does this seem like a good resolution?

from ansible.

Files identified in the description:

• lib/ansible/plugins/action/set_fact.py
• lib/ansible/modules/set_fact.py

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

from ansible.

The cause of this behavior is that the task defintion is only post_validated 1 time, which is when the task args are templated.

So before the set_fact task action plugin actually even executes, the task has been finalized with a static value, so it is not possible for until to expect a different result. Allowing this would have far reaching consequences.

Ultimately this is a duplicate of #78266

from ansible.

@sivel , thanks for your analysis. I saw #78266 was already closed.
Ansible is new to me. I am not sure what else I need to check for the reported issue. Could you suggest?

from ansible.

Ultimately, the work around would be to use a module instead of a lookup. For the file example you could use slurp in 2 tasks:

    - slurp:
        path: foo.txt
      register: result1

    - slurp:
        path: foo.txt
      register: result2
      until: result2.content != result1.content
      retries: 3
      delay: 10

For the dig example, you could use the command module:

    - command: dig +short {{ deployment_engine_fqdn }}
      register: result1

    - command: dig +short {{ deployment_engine_fqdn }}:
      register: result2
      until: result2.stdout != result1.stdout
      retries: 3
      delay: 10

Although you still could run into DNS caching related issues.

from ansible.

Thanks @sivel , I had a workaround for my playbook. Here I am trying to understand if the reported issue is a problem which needs a fix or not. If it is not an issue, I will get it closed.

from ansible.

You can also move the lookup so that it's part of the until condition, which does get evaluated each time.

- hosts: localhost
  vars:
    new_value: "{{ lookup('ansible.builtin.file', '/var/tmp/foo.txt') }}"
  tasks:
    - name: Set original fact
      ansible.builtin.set_fact:
        original_value: "{{ new_value }}"

    - name: Wait until the value changes
      ansible.builtin.debug:
        msg: Waiting for value to change from {{ original_value }}
      until: new_value != original_value
      retries: 3
      delay: 10

    - name: Display new value
      ansible.builtin.debug:
        msg: "{{ new_value }}"

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

TASK [Set original fact] *******************************************************
ok: [localhost]

TASK [Wait until the value changes] ********************************************
FAILED - RETRYING: [localhost]: Wait until the value changes (3 retries left).Result was:
    attempts: 1
    changed: false
    msg: Waiting for value to change from foobar
    retries: 4
ok: [localhost] =>
    msg: Waiting for value to change from foobar

TASK [Display new value] *******************************************************
ok: [localhost] =>
    msg: foo

from ansible.

Thanks @flowerysong, I used the same workaround as you mentioned. It worked.

from ansible.