Roles search path in 2.1 vs 1.9.4

Archives Ansible Project
1

I have an environment where we have multiple roles with the same name that vary depending on the environment they install in (don’t bother complaining about this). Some roles are common no matter which environment they are executed in, so I need to have fully realized inheritance. Part of the reason for this is that we are migrating from one environment to another and the legacy roles must continue to function without changes, but the new behavior has to be available as well.

This is the directory layout for one of the overloaded roles:

cassandra.yml
roles/
cassandra/…
…
aws/
cassandra.yml
roles/
cassandra/…

And I have the following in ansible.cfg at the top level:

additional paths to search for roles in, colon separated

roles_path = ./common:./roles

Under 1.9.4, if I execute:

ansible-playbook cassandra.yml

then the role that is used is “roles/cassandra”

On the other hand if I execute:

ansible-playbook aws/cassandra.yml

then the role that is used is “aws/roles/cassandra”.

This made perfect sense to me because the search path in ansible.cfg is “./roles” and that search path is relative to the playbook, not execution directory.

However, this exactly same directory structure under 2.1 always calls “roles/cassandra”.

In fact, I cannot figure out any way to get “aws/roles/cassandra” to get called, even if I cd into the aws directory. If I put anything in the roles_path that references the parent path, that poisons the search and the top level “roles/cassandra” gets called, e.g.

additional paths to search for roles in, colon separated

roles_path = ./common:./roles:…/roles

or

additional paths to search for roles in, colon separated

roles_path = ./common:…/roles:./roles

The sane way that a search path works is “first match”, but that doesn’t apply here.

Yes, I can use different role names. Yes I can create one role with really nasty conditional logic to handle the different environments. I want full inheritance where I can overlay a base class with a replacement (sometimes) and otherwise just get the base class. This used to work and not having it will require either that I avoid 2.1 (which isn’t really an option because I need the newer functionality) or refactor a large portion of my playbooks.

Thanks

John

2

To reply to my own post, this is apparently the same issue:

https://github.com/ansible/ansible/issues/16585

I’m going to see about patching this back to the way it worked in 1.9.4 because I think it was a mistake to change this core behavior. If I can, I’ll make it a config option, otherwise we’ll just run a patched version.