When running my playbook, on tasks that I have tried to name with variables, the variable name is there rather than the value.
Eg:
TASK: [weblogic | Create {{ tmp_dir }}] **************************
What do I need to change to get the tmp dir value output?
Thanks
In order for this to work the variable cannot be a host var or by extension not a group_var. It must be a variable that is defined globally such as from:
vars
vars_files
–extra-vars/-e
role invocation ( - { role: foo, some_var: bar } )
There are others, but the important thing is that vars from inventory, host_vars and group_vars will not work. The reason for this is that the var could be different for each host and it would make sense, as well as name being printed before the hosts are inspected.
I’ve noticed a couple behaviors with evaluating these:
The variable is not evaluated if only defined in the role’s “defaults/main.yml” variables file
None of the variables are evaluated if one of them wouldn’t be evaluated
Are these behaviors purposeful or just the result of how and when variables are put in scope? None of these variables are related to hosts (i.e. they are global).
I know that there is a hierarchy of variables and that they are looked for in a certain order, but where does Ansible look for variables before deciding how to display task names?
long one: #1 happens because of main/defaults.yml has the lowest precedence
possible and vars there don't get merged in until task execution,
name: gets set during task definition, this is because host vars are
allowed to override them. You can use vars/main.yml for 'non
overridable' higher precedence vars.
#2 happens because jinja2 is given the full name: string to evaluate,
and it throws a 'variable undefined error' (with default settings)
which we capture, ignore and return the original string, this is done
in some cases (like name:) as it should not play/task execution.
Using vars, extra vars or role vars (but not defaults) should give you
what you need for task names.
Basically think of it as each variable (for a large infrastructure) basically having 500 different values
Ansible can’t tell the variable has only one value, since the variable is “inventory scope” as such, it can’t plug it in, because the task header (that preceeds the next 500 task results) would not apply equally to all hosts.
So it’s a cosmetic thing, but done for a very good (if not slightly confusing!) reason.
Now it would seem to me that if everyone’s explanations were correct that my task should have failed, because “{{ package_versions.app.oraclejre_version }}” should not resolve properly AT ALL for the reasons that everyone has stated. But you can see that it IS resolving properly : “path”: “/usr/local/java-jdk1.7.0_75”. So why would it resolve properly in the file: field but not the name: field?
The variable handling changed and the callback isn't getting the
variables it needs anymore. Defered to v2 because one of the goals of
v2 is to simplify variable handling which should make this easier to
fix. (and any fix that was to hit v1 wouldn't be applicable to v2).
I'm not sure I see the reason you have for thinking it won't resolve at all...
In general the difference between the name field of a task resolving
and the same variable within a task is that the name field is
templated once per task whereas the parts that make up what is
executed in the task are templated once per host. So something that
is at the host/group level can't be known at the time that we template
and print out the name field. But it will be known by the time we
loop over the task body.
You could think of it sort of like this pseudo code:
global_vars = resolve_globals()
print (template(name_field, global_vars))
for host in hosts:
host_and_group_vars = resolve_host_and_group(host)
execute(template(task, global_vars, host_and_group_vars))
( Any of these specific cases could be because of the bug I linked to
later in the thread: https://github.com/ansible/ansible/issues/10347
but I can't guarantee it... there are certain variables that simply
aren't available at the time the name field is printed but are
available once we start looping over the task itself.)