Ansible skipping the rest of the tasks after one conditional task

[Joshua J. Kugler]

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

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

--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: peda...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A

[Brian Coca]

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.


--
Brian Coca

[Joshua J. Kugler]

On Tuesday, October 27, 2015 20:51:41 Brian Coca wrote:
> 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.

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.

[Brian Coca]

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

> --
> 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 ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6806121.tnrxovJNzW%40hosanna.
> For more options, visit https://groups.google.com/d/optout.



--
Brian Coca

[Joshua J. Kugler]

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

[James Cammarata]

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.

James Cammarata

Director, Ansible Core Engineering

github: jimi-c

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1813492.f1nZqG25fM%40hosanna.

[Joshua J. Kugler]

On Wednesday, October 28, 2015 15:07:45 James Cammarata wrote:
> 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.

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!