meta/requirements.yml

[bcoca]

Proposal: standard location for requirements

Author: Brian Coca (@bcoca)

Date: 2017/03/33

• Status: New
• Proposal type: core design
• Targeted Release: future release
• Estimated time to implement: X days/weeks/etc

Motivation

Plays that use 3rd party roles have to manually deal with requirements, also roles cannot easily provide their requirements making a requirement chain hard to follow.

Problems

Easy installation of requirements for a playbook (currently just roles).

Solution proposal

New 'standard' file: meta/requirements.yml, that can exist at either role or adjacent to play (role already has meta/ dir).

The file structure would be the same as current role requirements.yml, as it now lives in a 'predictable' place we can chain then when doing role installs.

Related

This would make autoinstall a lot easier https://github.com/ansible/proposals/issues/7 possibly related to/subset of ansible-config https://github.com/ansible/proposals/issues/35

[cchurch]

:+1: for a standard location for AWX/Tower to find Galaxy requirements (currently supports only roles/requirements.yml).

[bcoca]

@cchurch was thinking of keeping 'role requirements' there .. but now i'm favoring meta/ directories (in role or adjacent to play)

[kustodian]

Would really like to see this added. Current installing of dependencies by ansible-galaxy is awesome, but it lacks flexibility of executing dependent roles in the middle of the role using (import_role/include_role).

Any news about this? It should be an easy thing to implement, but it would make it a lot easier to install dependent roles.

I would even be willing to make a PR for this :)

[bcoca]

@kustodian we are currently discussing this both in IRC meetings and internally as there are other plans for installing galaxy content that could be affected by this and/or duplicate efforts. I hope i can give you an answer soon.

In any case I think the initial scope should be 'role only' we can expand (or not) to play and other levels later.

[kustodian]

@bcoca that's great news and just adding it to roles for now is the most important.

[thaumos]

Hi @kustodian, as @bcoca mentioned a lot is in flight at the moment. We're focusing a lot of our efforts on this and other areas of Galaxy. Stay tuned for more info in the coming months!

[kustodian]

May I join the discussion somewhere?

[webknjaz]

@kustodian there's logs of IRC meetings you might want to check: https://github.com/ansible/community/issues?utf8=%E2%9C%93&q=is%3Aissue+Public+Ansible+Project+Meeting+Agenda

It was mentioned at least @ https://github.com/ansible/community/issues/329

[bernardoVale]

any updates?

[DaazKu]

@bcoca @sivel

I've already tried to solve the dependency problem without knowing about this proposal and would still like to solve this since it forces users to use external/homebrew tools but I don't want to work for nothing.

Can one of you tell me the likeliness of an implementation of this proposal being merged in 2020 if I were to do it?

[sivel]

@DaazKu Without seeing an implementation of the feature, I cannot say whether or not it would be accepted. Also depending on when it is submitted, when the review is complete, and when we would decide to merge, it may or not make it into the 2.10 release.

Everyone runs the risk of doing work, and it not being accepted, this happens to even @bcoca and myself.

[AlanCoding]

👋 We have started a project called ansible-builder which will build images (execution environments).

https://github.com/ansible/ansible-builder

Let me call attention specifically to the section "Collection Execution Environment Dependencies" in the README.md. The form of dependency specification it accepts is built from existing common practices among collections, and there have been many collections that required no modification.

I want to start the conversation about how this can be the solution for some of the problems discussed here.

[sivel]

We do now support meta/requirements.yml in roles. As it is this proposal could be closed, but I'll hold off on doing that for now.

[geerlingguy]

@AlanCoding - I think https://github.com/ansible/proposals/issues/158 may be more relevant to the Execution Environment dependencies since that deals more with the module deps :) — I think I missed that in my earlier searches.

[profhase]

@sivel I have found https://github.com/ansible/ansible/pull/68288 but I cannot find anything about meta/requirements.yml in the docs. Is it a feature that can already be used?

[DaazKu]

@profhase https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#dependencies

[sivel]

Closing.

[alexander-rabenstein]

How can meta/requirements.yml be used to install collections? With ansible-galaxy its not possible to have something like this: `roles:

• name: testrole src: https://dev.azure.com/XXX scm: git version: master collections:
• ansible.windows
• community.windows`

I get ERROR! Expected role dependencies to be a list.

[bcoca]

this proposal was not implemented, the alternative is what the link above documents

[alexander-rabenstein]

Sorry to nag, which document do you mean? Do you mean: https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#dependencies

Because there it states meta/requirement.yml is implemented from 2.10, but it doesnt state which version of the requirements file (with roles and collection keywords or as simple list)

[DaazKu]

The implementation that was made at the time, for roles, only works for roles. It was never updated/implemented to work with collections.

[sivel]

It was never updated/implemented to work with collections.

Nor will it be. There is NO planned activity to allow roles to list collections they depend on that will allow them to be automatically installed, nor a collection to list roles they depend on.

[bcoca]

you can have a requirements.yml (not in meta/) that holds both dependencies but both will not be automatically installed, only the same type as the current object installed, it requires a 2nd run of ansible-galaxy with the other object type to finalize.

[alexander-rabenstein]

Ok but should the meta folder describe the role? So argument_spec.yml meta.yml requirements.yml

How should somebody who wants to use a role from galaxy know what the collection requirements for this role are? From my perspective the user would install the role with ansible-galaxy and the try to run it and learn about the missing collections the hard way.

Sorry to reopen this "old" proposal, perhaps I miss something here.

[sivel]

A stand alone role should generally not have collection requirements. Migrate that role into a collection, and then it can have requirements on another collection. Otherwise, you are basically going to just have to add instructions to the readme that explain the need to install additional dependencies.

[geerlingguy]

My solution to this problem right now is to tell people using roles to generally try to install ansible (the community version with batteries included), as most roles were built assuming that already.

As time goes on, and more roles are built directly into collections, or roles are slowly upgraded to use FQCNs and such, this won't be an issue anymore, but there will likely still be a long transition period, and the easiest answer (and what I do) is to just install the full community edition since 99.9% of the modules standalone roles on Galaxy use will be part of that for a long time to come.

[alexander-rabenstein]

Our use case are windows targets, so in almost every role we write we require ansible.windows and community.windows. Also we are using Ansible automation plattform, so I want to keep this as automatic as possible.

The automatic installation is one part of the problem, the otherside is documentation. We plan on having a ci pipeline automatically creating docs for our roles, including the information from meta (argument_spec, deps, author etc)

So this also about having the documentation in a structured format. I sure could simply put a collections.yml in /meta but I thought there would be an ansible way to do this.

[alexander-rabenstein]

Also as an addition, even if we would use collections, we would either need to have single collection for each role, because I would also like to track which role needs / uses which collection, so If we would put multiple roles into one collection we still would lose the information which role uses which collection.

So apart from the automatic installation dependency management and tracking is not solvable with how its implemented currently.