All about Roles in 1.2 -- a great way to organize best-practices content

Archives Ansible Project
21

The last piece that still feels missing to me (at least for my use case)
is the templates and files. With the new roles structure the default
location for these is relative to the role directory. This works fine when
the template as is can be sufficiently represented with various jinja
interpolations. And for files its okay when the file is model/role specific
and not app+environment relevant. However I have use cases where the
app+environment can(/may need to) override the whole template, and/or
potentially use its own file/* ref'd in the playbook. Would it make sense
to lookup templates and files first relative to the hosts file, then
fallback to role location?

You can still reference other paths in these cases by specifying a
different path, it looks in two places, basically.

I do not think looking in a path relative to the host file is neccessarily
a good idea, just because that I think crosses the streams too much between
inventory data (this is something about my geography or hosts) and
playbooks (this is a description about what I am deploying onto these
hosts).

This is something I do today which allows the app to own its own templates
& files (pulled from their git repo), if desired, via first_available_file
and some path hackery. But it seems to make sense to have this capability
'built in' where the templates/files default to the roles subdir but can be
overriden relative to the 'inventory' if necessary.

Hmm, yeah I understand, but am worried if we include too much magic the
playbook could not be read "at first glance" to know exactly what it would
do, and that behavior is also important to me.

22

Agreed regarding too much magic. I found one way to do this simply using the 1.2 devel branch:

23

Disregard this. The roles implementation at this point is inconsistent as far as template and copy go when using first_available_file. W/o and directly using src is will search relative to the role dir (as in the roletest.yml example). W/ first_available_file it will go back to using the playbook source dir :-(.
Should I file a bug or is this implementation still in the works?

One other note: I noticed that using {{ vars.inventory_dir }} actually generated an error: recursive loop detected in template string: {{vars.inventory_dir}}. Oddly though using {{vars.inventory_dir}} as a debug msg value worked. However ${vars.inventory_dir} worked in both cases.

So the below works, but as mentioned above first_available_file is relative to playbook dir which kinda defeats the purpose of the roles dir structure.

$ /ansible/examples/playbooks$ cat roles/bar/tasks/main.yml

24

Hi,

What about the following (untested) approach of default values that is implemented as a hack, but could be part of the core:

playbook.yml

25

If a variable wants to be used throughout a role, then its default values and overrides could be stored back into a variable like this (although a better alternative to debug module would be nice):

  • debug: msg=“{{ item }}”
    register: var1
    with_first_found:

  • “{{ var1 }}”

  • foo

  • name: access the variable whose default value can be overriden
    shell: echo {{ var1.results[0].msg }}

Greetings,
gw

26

I’m sorry, this doesn’t really make sense, it is rather specific and would spam lots of data, and add lots of undue code.

Roles could contain variables that reference variables not yet defined – Ansible allows this, so it would not be perhaps as useful as you may think.

Some folks may have 5 simple scalar values in a role, others may have a four page nested hash table.