include: and variables (changed in 1.8?)

[Ross Becker]

So, I have a batch of playbooks that include tasks where the filenames are determined by variables;

 - include: tasks/mytask-{{onevar}}-{{anothervar}}.yml

This was working up through ansible 1.7.2.   As of ansible 1.8.0 (and also tested on ansible 1.8.1) this stopped working;  the variables are no longer interpreted, and ansible exits complaining with a message:

1. ERROR: file could not read: /root/work/playbooks/tasks/bar-{{platform}}.yml

Below are the bits to reproduce:

1. foo.yml:
2. - hosts: slave
3.   user: root
4.  
5.   vars:
6.     platform: rpm
7.  
8.   tasks:
9.     - include: "tasks/bar-{{platform}}.yml"
10.  
11. tasks/bar-rpm.yml:
12. - name: install OS package dependencies
13.   action: yum pkg={{item}} state=installed
14.   with_items:
15.     - wget
16.     - ntpdate
17.  
18.  
19. hosts.inv:
20. [slave]
21. sc-cluster-20-04
22. sc-cluster-20-05
23. sc-cluster-20-06

The above case works on all ansible versions up through 1.7.2, and breaks on 1.8.0+.  I searched on here a bit regarding this, and found the suggestion that variables as part of include filenames would only work if passed in as extra vars, as only those would be resolvable early enough.  I tested that on 1.7.2 by taking out the "vars:" section and passing the value in as an extra var on the command-line.  That test worked on 1.7.2 and earlier, but does not work in 1.8.0+.  

Is there any means where this functionality should actually work in 1.8.x?

[Brian Coca]

a few bugs with variables were present in 1.8.x, could you test with
current devel as there are fixes there (soon to be released) that
might solve your issue.

> --
> 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/c2604edb-dc50-4770-82e1-d638e099b766%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Brian Coca

[Ross Becker]

Ahah- yes, it works again when I tested ansible at current git state.  OK, I'll make sure that we're pegging our ansible version to 1.7.2 for the moment, and wait for the next release to pull that back out.  Thanks!

[Michael DeHaan]

Also I'd double check that those two vars in the include do not come from facts or inventory.

(That would have been any any-version thing)

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJ5XC8kLBbfRctHR2nKSjPu4P_p3d3OGnZxpydRc7qgQEwxwDw%40mail.gmail.com.

[Ross Becker]

Funny enough, in prior versions and in dev branch, having those facts come in via a "vars:" statement in the playbook works.  Most places they're being used, they come in via extra-vars, and it wouldn't have been a big deal to change this instance to match that, but not working at all would've been a big deal.

[ali...@curationexperts.com]

I'm trying to use a task where the filenames are determined by variables, running into what looks like the same issue, and wondering how best to accomplish what I want to do. I'm using Ansible 1.9.1.

Within a role, I have two task files for installing two versions of the same component that install in different ways.

In the role's defaults, I have two variables: component_version and component_main_version.
The component_main_version variable is defined in the defaults/main.yml this way:
component_main_version: "{{ component_version[0:1] }}"
My intention is to pull the main version number (e.g. 4) from the full version number (e.g. 4.8.1).

In tasks/main.yml, I have - include: component_{{ component_main_version }}.yml.
When I run my playbook I get
ERROR: file could not read: /path/to/role/tasks/component_{{ component_main_version }}.yml
If I pass the variable at the command line:
-e component_main_version=4
I get the desired behavior.

Am I defining the derived variable incorrectly? Am I running up against the bug described here? Is there a better way to accomplish what I'm trying to do?

Any insight/help greatly appreciated.
Thanks,
Alicia