change in behaviour of "when:"

Archives Ansible Project
1

Hi All,

I currently have this…

- shell: “[ -f /etc/ldap/.done_slapd ] && echo ‘done’ || echo ‘’”
register: result

- dpkg_reconfigure:
pkg: slapd
answers:
slapd/password2: $ldap_pass
slapd/password1: $ldap_pass
slapd/invalid_config: true
shared/organization: $ldap_org
slapd/no_configuration: false
slapd/purge_database: false
slapd/domain: $ldap_domain
slapd/backend: HDB
when: result.stdout.find(‘done’) == -1

- command: touch /etc/ldap/.done_slapd creates=/etc/ldap/.done_slapd

and its failing with

PLAY [ldap_master] ************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.252.102]

TASK: [slapd | apt name= state=present] ***************************************
fatal: [192.168.252.102] => error while evaluating conditional: {% if result.stdout.find(‘done’) == -1 %} True {% else %} False {% endif %}

FATAL: all hosts have already failed – aborting

PLAY RECAP ********************************************************************
to retry, use: --limit @/home/jtang/ldap.retry

192.168.252.102 : ok=1 changed=0 unreachable=1 failed=0

This used to work before I recently pulled the latest development version of ansible. It seems to want to do something smart with the result.

Jimmy.

2

If you can share an example that doesn’t require running slapd (how about echo or something?), please file an example ticket in github that reproduces it.

I’m not sure how “latest” you were here but happy to look.

3

Hi Michael,

I was testing against ansible 8faaae142ce84ae8029520c4d0a4cc343bbc9070, I think I’ve managed to create a test case for this. I’ll test abit more then log a ticket, but it looks like it has to do with roles…

Jimmy

4

Hi Michael,

Please see https://github.com/jcftang/vars-failure-evaluation I’ve managed to recreate the failure.

Thanks,
Jimmy

5

Thanks, looking at this now!

6

Should be good to go now.

This was a result of the work last night to add deprecation warnings, and a variable wasn’t being copied properly while parsing the included tasks, which resulted in conditionals occasionally being applied to tasks they were not intended for.

While cleaning this up, I also took the opportunity to improve the error message on failed conditionals to not present all the internal “if True / False” logic – which the user doesn’t need to know about – when explaining which conditionals failed. That seems to be a popular question so should greatly simplify things.