CODEWITHSUNDEEP
ansible
papanito
papanito

Reputation: 2574

Ansible role dependency handling for collections

When creating an ansible role you can specify the dependencies in meta/main.yml as follows

dependencies:
- role: papanito.xxx

How I do this, if papanito.xxx was converted into a collection? Or let's phrase it otherwise: How to I tell my role, that it depends on a module/role from a collection?

If I run ansible-playbook which uses a role, that has a dependency to a role in a collection, get the following error:

ERROR! the role 'papanito.xxx' was not found in ansible.legacy:
/home/papanito/Workspaces/devenv/roles:
/home/papanito/.ansible/roles:
/usr/share/ansible/roles:
/etc/ansible/roles:
/home/papanito/Workspaces/devenv/roles:
/home/papanito/Workspaces/devenv

As I can see ansible checks these paths for roles, however, collections are stored under /home/papanito/.ansible/collections/ansible_collections/.

I suspect this has to do with the mention of ansible.legacy, however I did not configure anything like that - intentionally at least.

Using role: the_namespace.the_collection.the_role does not solve the problem, but I still get the same error.

Further the documentation says

Within a role, you can control which collections Ansible searches for the tasks inside the role using the collections keyword in the role’s meta/main.yml

So I updated meta/main.yml to

collections:
- papanito.xxx
dependencies:
- role: papanito.xxx.xxx

Which still results in the exact same error as above when I run the playbook.

Upvotes: 14

Views: 9124

Answers (1)

papanito
papanito

Reputation: 2574

So apparently this is not really supported. A detailed explication can be found in issue #76030

A stand alone role is not meant to depend on a collection, just as a collection is not meant to depend on a stand alone role.

It can be achieved technically, but users will be required to resolve the dependencies manually.

As such, collections should only depend on collections, and stand alone roles should only depend on stand alone roles.

In the comments you also find some more technical details on why this is not implemented:

Role and collection dependencies are handled entirely separately in ansible-galaxy currently because roles are less structured than collections. The role dependency builder doesn't create a full dependency tree, just considers what's currently getting installed. Roles have no versioning schema, can be renamed at install-time, support extra source types, etc, so the first step would be to reconcile those differences, including making some backward-incompatible changes to standalone roles like requiring semantic versioning. Once that's done, the role dependency resolution in ansible-galaxy could be ported to resolve the full dependency tree in the same way as collections (still entirely separate from collections, just using common code).

ansible-galaxy doesn't look at roles in collections, so the next thing would be for Galaxy/AH to inspect collection content and support querying dependency information inside collection roles (and role collection requirements). Otherwise, all-potential collection/role candidates would need to be downloaded to a temp location just to inspect the cross-type requirements inside them and find the best candidates that are compatible with everything else, before installing.

Upvotes: 9

Related Questions