Ansible collection naming

brettweir commented

2026-09-19 21:43:13 +00:00

Member

We need to lock in the names for our Ansible collection(s).

We have a role defined (postinstall) and a second one on the way it sounds like (wildfly?). I have a few roles to contribute as well: a jellyfin role and an httpd role with corresponding httpd_proxy role to start with.

All of these roles make sense to inhabit the same collection, which then lives inside the fedoraserver namespace, which we've claimed. The name that end users will use to run the postinstall role with be:

fedoraserver.<collection>.postinstall

So we need to decide on a name! There's a big question to answer.

Should we put everything in one collection? Or create one collection for core setup and other collections for applications?

I see a lot of benefit to the second approach.

For a similar example: community.general has tools most system administrators need, but there are other collections like community.postgresql and community.mysql that offer lots of roles for a specific application.
Collections can be released independently reducing blast radius and making it easier for collaborators to work independently.

You don't have to look to see precedent for this firsthand either:

 ansible-collection-ansible-netcommon.noarch    Ansible Network Collection for Common Code
 ansible-collection-ansible-netcommon-doc.noarch        Ansible Network Collection for Common Code - Docs
 ansible-collection-ansible-posix.noarch        Ansible Collection targeting POSIX and POSIX-ish platforms
 ansible-collection-ansible-utils.noarch        Ansible Network Collection for Common Code
 ansible-collection-ansible-windows.noarch      Windows core collection for Ansible
...
 ansible-collection-community-crypto.noarch     The community.crypto collection for Ansible
 ansible-collection-community-docker.noarch     Ansible modules and plugins for working with Docker
 ansible-collection-community-general.noarch    Modules and plugins supported by Ansible community
 ansible-collection-community-internal_test_tools.noarch        Internal test tools for other collections
 ansible-collection-community-kubernetes.noarch Kubernetes Collection for Ansible
 ansible-collection-community-library_inventory_filtering_v1.noarch     Library collection with helpers for inventory plugins
 ansible-collection-community-libvirt.noarch    Manages virtual machines supported by libvirt
 ansible-collection-community-mysql.noarch      MySQL collection for Ansible
 ansible-collection-community-postgresql.noarch Manage PostgreSQL with Ansible
 ansible-collection-community-rabbitmq.noarch   RabbitMQ collection for Ansible
...

But this only makes sense if the scope of our roles is large.

With this in mind, we should create fedoraserver.general to start with, and put postinstall there. Then assess on an app-by-app basis whether another collection is needed.

We should rename the ansible-support project to follow this:

ansible-collection-fedoraserver-general

Then release the collection as:

fedoraserver.general

So that users can implement fedoraserver.general.postinstall in their playbooks.

I'm not committed to the word general. core also would work, but I thought general was more descriptive. I'm open to other suggestions.

Project names are difficult or impossible to change once we start releasing! I want to make sure we get this right!

We need to lock in the names for our Ansible collection(s). We have a role defined (`postinstall`) and a second one on the way it sounds like (`wildfly`?). I have a few roles to contribute as well: a `jellyfin` role and an `httpd` role with corresponding `httpd_proxy` role to start with. All of these roles make sense to inhabit the same collection, which then lives inside the `fedoraserver` namespace, which we've claimed. The name that end users will use to run the `postinstall` role with be: ``` fedoraserver.<collection>.postinstall ``` So we need to decide on a name! There's a big question to answer. **Should we put everything in one collection? Or create one collection for core setup and other collections for applications?** I see **a lot** of benefit to the second approach. - For a similar example: `community.general` has tools most system administrators need, but there are other collections like `community.postgresql` and `community.mysql` that offer lots of roles for a specific application. - Collections can be released independently reducing blast radius and making it easier for collaborators to work independently. You don't have to look to see precedent for this firsthand either: ``` ansible-collection-ansible-netcommon.noarch Ansible Network Collection for Common Code ansible-collection-ansible-netcommon-doc.noarch Ansible Network Collection for Common Code - Docs ansible-collection-ansible-posix.noarch Ansible Collection targeting POSIX and POSIX-ish platforms ansible-collection-ansible-utils.noarch Ansible Network Collection for Common Code ansible-collection-ansible-windows.noarch Windows core collection for Ansible ... ansible-collection-community-crypto.noarch The community.crypto collection for Ansible ansible-collection-community-docker.noarch Ansible modules and plugins for working with Docker ansible-collection-community-general.noarch Modules and plugins supported by Ansible community ansible-collection-community-internal_test_tools.noarch Internal test tools for other collections ansible-collection-community-kubernetes.noarch Kubernetes Collection for Ansible ansible-collection-community-library_inventory_filtering_v1.noarch Library collection with helpers for inventory plugins ansible-collection-community-libvirt.noarch Manages virtual machines supported by libvirt ansible-collection-community-mysql.noarch MySQL collection for Ansible ansible-collection-community-postgresql.noarch Manage PostgreSQL with Ansible ansible-collection-community-rabbitmq.noarch RabbitMQ collection for Ansible ... ``` But this only makes sense if the scope of our roles is large. With this in mind, **we should create `fedoraserver.general` to start with, and put `postinstall` there**. Then assess on an app-by-app basis whether another collection is needed. We should rename the `ansible-support` project to follow this: ``` ansible-collection-fedoraserver-general ``` Then release the collection as: ``` fedoraserver.general ``` So that users can implement `fedoraserver.general.postinstall` in their playbooks. I'm not committed to the word `general`. `core` also would work, but I thought `general` was more descriptive. I'm open to other suggestions. **Project names are difficult or impossible to change once we start releasing! I want to make sure we get this right!**

brettweir changed title from ~~Ansible collection naming~~ to Ansible collection names

2026-09-19 21:44:49 +00:00

brettweir changed title from ~~Ansible collection names~~ to Ansible collection naming

2026-09-19 22:02:15 +00:00

pboy commented

2026-09-19 22:53:33 +00:00

Owner

I'm wondering. As I know the concept of namespaces, if we own 'fedoraserver', nobody can claim fedoraserver.whatilike without our consent?

brettweir commented

2026-09-19 23:34:56 +00:00

Author

Member

Correct, as far as Ansible Galaxy goes, no one else can publish under fedoraserver and we can publish any number of collections we want.

Correct, as far as Ansible Galaxy goes, no one else can publish under `fedoraserver` and we can publish any number of collections we want.

pboy added the

Ansible

basic support

label

2026-09-20 06:38:19 +00:00

eseyman commented

2026-09-20 21:10:35 +00:00

Member

and a second one on the way it sounds like (wildfly?)

FTR, this is the wildfly collection from Ansible Galaxy which I hope to package this week as an rpm.

> and a second one on the way it sounds like (wildfly?) FTR, this is the [wildfly collection](https://galaxy.ansible.com/ui/repo/published/middleware_automation/wildfly/) from Ansible Galaxy which I hope to package this week as an rpm.

🎉 1

brettweir commented

2026-09-21 23:36:44 +00:00

Author

Member

@eseyman wrote in #265 (comment):

and a second one on the way it sounds like (wildfly?)

FTR, this is the wildfly collection from Ansible Galaxy which I hope to package this week as an rpm.

That'll be nifty!

@eseyman wrote in https://forge.fedoraproject.org/server/tickets/issues/265#issuecomment-1358632: > > and a second one on the way it sounds like (wildfly?) > > FTR, this is the [wildfly collection](https://galaxy.ansible.com/ui/repo/published/middleware_automation/wildfly/) from Ansible Galaxy which I hope to package this week as an rpm. That'll be nifty!

eseyman commented

2026-09-22 16:36:43 +00:00

Member

+1 for fedoraserver.general.postinstall

brettweir commented

2026-09-25 09:03:21 +00:00

Author

Member

We ended up agreeing on fedoraserver.general. Closing.

We ended up agreeing on `fedoraserver.general`. Closing.

brettweir closed this issue

2026-09-25 09:03:21 +00:00

Rows
Columns

Ansible collection naming #265