Collections requirements for role or playbook-focused collections?

[geerlingguy]

SUMMARY

I imagine that at some point, someone may want to submit a collection having either all roles and/or playbooks, or primarily roles and/or playbooks.

What are the criteria for inclusion for this? It seems the current proposed requirements lack any specifics about roles/playbooks, or anything besides plugins/modules.

For example, should roles/playbooks pass ansible-lint? How are they to be tested? How can we prevent having 700 nginx roles shipping with Ansible?

ISSUE TYPE

• Bug Report

[felixfontein]

The current requirements are taylored at collections with plugins/modules since 2.10 was about including the collections which contained content that was moved from ansible/ansible, which was plugins and modules :) So this part is definitely missing!

I guess roles need to have tests (ansible-test or molecule), and ansible-lint (with a specific config, not necessarily the default config) and yamllint for sanity checking sounds like a good start.

Right now I'm totally unsure of what kind of roles/playbooks collections we should accept. We definitely should avoid having too many, and avoid unnecessary duplication (like 700 nginx roles). Roles/playbooks should probably be sufficient generic that they cover a large range of needs, without being too generic that they are too hard to use. (Don't ask me how to properly formalize that ;) )

[jillr]

The Cloud team is developing a collection of all roles now but I don't think it had occurred to us to try to include it in the ansible package. It would certainly be worth having guidance for these types of collections in the docs.

I'd agree with tests and linting. Designing a standard for usefulness/notability/etc is going to be a pretty massive undertaking to get consensus on though, so I'd start by asking if this is something that we should block the initial collection inclusion criteria on deciding. Or should we initially (for the December deadlines) focus on collections of modules/plugins and add role/playbook collection criteria in a future revision of the requirements so we have time to adequately debate this one?

[felixfontein]

I'm +1 for skipping role/playbook only collections for 3.0.0, since I'm pretty sure we won't have a good idea until then. It still would be nice if such collections could apply, so we already have a set of candidates (for 4.0.0 or later) and can take a look at how candidates would look like :)

[dmsimard]

Thanks for bringing this up @geerlingguy, I hadn't thought about this and it's a pretty compelling use case.

Going slightly off topic to see how this might end up being used, I feel it's quite a pandora's box we opened: Ansible has historically never shipped roles or playbooks before and now they can be included by way of collections.

For playbooks, it might be a bit complicated to consume them since you'd need to supply the full path a bit like:

pip install ansible
ansible-playbook /path/to/python/site-packages/ansible_collections/community/general/playbooks/something.yml

Edit: turns out there's a PR to allow running playbooks based on the FQCN: ansible/ansible#67435

For roles, though, I see this as an opportunity to do something like:

pip install ansible
ansible localhost -m include_role -a "name=community.general.something"
# or doing an include_role in a "personal" playbook

I could very much see myself including roles out of the Ansible package directly but I also wonder about the impact on installation times that have already gone up since 2.9. How are we going to keep control over the size of the package ?

[samccann]

Since this hasn't been completely resolved, I opend a forum topic to see if we can get resolution here - https://forum.ansible.com/t/criteria-for-role-or-playbook-focused-collections-in-ansible-package/5954

We'll be archiving this repo so closing this issue now.