Ansible skipping the rest of the tasks after one conditional task

Archives Ansible Project
1

So, granted, I'm rather new at Ansible, this is really not fitting my
understanding of Ansible. :slight_smile:

I conditionally include this file:

https://gist.github.com/jkugler/3c683b539575ba4f0d66

The condition that includes it is satisfied, and it is included. The first task
runs (the stat to check for a file). This causes the second task to skip, since
"st.stat.exists == False" is not so (i.e. don't run if the file exists).
However, then the rest of the tasks in that file are skipped as well, even
though they have no "when" conditional on them.

Footnote: I know I don't have to do the stat check before the get_url. I had
named a file wrong, and get_url was failing, and I wasn't understanding the
error message, thus the stat call. But it did bring up this odd behavior that
I would still like to understand.

j

2

the when in the include is applied to each included task, if it also
relies on the st variable it would explain what you are seeing.

3

I'm not sure I'm following. Are you saying you can't reuse register
variables? Here's how it worked in my task:

- name: Does the prepared ISO exist?
  stat: path=/var/lib/ISO/CentOS-6.7-x86_64-minimal/.treeinfo
  register: st

- name: Get it and prepare it if not
  include: get_centos_67.yml
  when: st.stat.exists == False

So, when it includes the file, the condition is true. It then walks through
https://gist.github.com/jkugler/3c683b539575ba4f0d66

The first thing it does is another stat, which is stored in 'st'. In this case,
'st.stat.exists == False' is false, because the file is there, which mean it
skipped the download. Once I removed the 'when' in the above gist, it
properly processed the file. It *SEEMED* the 'when' in the gist was affecting
the rest of the steps in the gist.

j

4

no, im saying that if you had a condition on the include, each task
inherits it and evaluates it when run

so even if you don't have an explicit condition on them you have an implicit one

5

OK, so the condition for the include was satisfied, which means for each step
in the file should have the condition satisfied.

Are you saying because I used the same var in both places, the *second* use of
'st' is used to evaluate the 'when' condition that is implicitly applied to
all the included steps? That sounds like a scoping problem, if so.

j

6

Registered variables are stored on a per-host basis, and thus are always visible to the host when it’s compiling its variables. So it’s not really a scoping problem, as it’s not tied to the include. Now, if you passed the variable in as a parameter to the include, it would in fact limit the scope to that include.

7

OK, that makes sense. First part of the confusion came because I didn't
realize Ansible eval'ed the 'when' condition for each step of the include.
Probably didn't remember reading that in the docs.

As for the scoping, to be sure I'm understanding:

The "outer" file creates a var called 'st' and uses it in the 'when' to include
<file>.

<file> has a step which registers its result in 'st' (and changes the value in
this case).

The outer file then re-evaluates the 'st' var (which is the *same* var), sees
the condition is no longer true, and skips the rest of the steps.

That's actually kind of handy...the included file could short-circuit its own
execution if it changed the value of the var used in the 'when'.

Much thanks to you and Brian for your patience in walking me through this!

j