Roles search path in 2.1 vs 1.9.4

21 views
Skip to first unread message

jpea...@sparkpost.com

unread,
Jul 14, 2016, 12:51:01 PM7/14/16
to Ansible Project
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

jpea...@sparkpost.com

unread,
Jul 14, 2016, 3:23:27 PM7/14/16
to Ansible Project


On Thursday, July 14, 2016 at 12:51:01 PM UTC-4, jpea...@sparkpost.com wrote:
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.

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


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.
Reply all
Reply to author
Forward
0 new messages