Reasoning behind moving every role into one repository?

[hhenkel]

Hi, I would like to know what the reasoning is behind moving every role into one git repository. I understand that 'collections' are now a thing - but currently one is not really able to host his own collections, which makes it a bit pointless in a disconnected setup.

Besides this general problem I try to understand why you not use git submodules and leave the roles in their own git repositories. This would allow people to still use your roles and also give the option to have collections.

Kind regards,

Henning

[greg-hellings]

Hi, Henning,

Moving our roles into a collection was driven by a few considerations:

• It allows more rigorous testing of PRs, especially those that impact the early roles in the pipeline. A change to one role will trigger CI testing across the whole collection
• It allows us to share any modules or filters we develop across the whole collection without needing to duplicate code or include a separate role
• It allows us to easily share test code across the entire collection without the need for duplication

As for keeping it as a single repo rather than using git submodules for every role, we have additional benefits as well, like:

• A single PR can update multiple roles
• Managing issues and PRs in a single place becomes feasible
• Individual roles don't as easily fall behind on our best practices just because they have been bug-free and feature complete for a long time
• Releases are much easier than with separate repos held together by git submodule as we never have to worry if one of the roles is out of date in the submodule entry. We just tag and push to one repo and everything of consequence is already in it

I'm not sure what you mean when you say "one is not really able to host his own collections". I'm pretty sure a collection can just be a .tar.gz file that you build with ansible-galaxy collection build and then can transfer around. Alternatively, you can just checkout a git repo and set ANSIBLE_COLLECTIONS_PATHS in your environment to the proper directory structure and you can bring along any collection you want. People are very much still able to use our roles when they're in a collection.

[hhenkel]

Hi Greg,

thanks for the reply. I can see the points you're making in regards of managing it all in one repository.

I'm not sure what you mean when you say "one is not really able to host his own collections". I'm pretty sure a collection can just be a .tar.gz file that you build with ansible-galaxy collection build and then can transfer around. Alternatively, you can just checkout a git repo and set ANSIBLE_COLLECTIONS_PATHS in your environment to the proper directory structure and you can bring along any collection you want. People are very much still able to use our roles when they're in a collection.

Yes, you'e right this is totally possible to clone the collection git locally. Sad thing here is, that the ansible-galaxy command only works with a "real" ansible galaxy. Currently I'm not aware of any proper, supported solution to host your own galaxy, however I'm aware that Red Hat is working on that in the context of pulp. I for sure can also build my own tar.gz and move it around as you said, but for me currently the ecosystem is not yet ready. Especially when you have ansible tower in place, which checks out all the things you name in the requirements.yaml it does not feel "right" to have build work arounds to be able to use collections.

In my case we just use two of your roles in our playbook/workflow that is based on the idea of puppets roles & profiles. Having a requirements.yaml pointing to a git repository is a straight forward, working solution without the need to jump through loops.

However this is probably more a general rant about things and the reason why I cared to ask. Thanks again for you answer.

[greg-hellings]

So it's not too much of a workaround. "ansible-galaxy collection install ..." accepts a path directly to a .tar.gz file with the built collection, including one hosted at a remote URL. Building the collection is as simple as grabbing the repo and executing "ansible-galaxy collection build" from the root of it (sadly it can't install directly from the source tarball provided by Github).

As for installing from other installs of Galaxy, it claims to support that. From that link you can see that you set the URLs to different servers in your ansible.cfg file and then provide it the ordered list of which servers to check in which order using the "server_list" setting. I haven't tested this, but it's documented at that link and more thoroughly at others. So if it doesn't work, that's a big shame.

However, from tower's perspective, it should just be necessary to host the built tarballs somewhere. You can either build them yourself or download them, such as here. Then put them on a web server that your Tower installation can reach and point your requirements.yml file at that URL.