[debops-users] Opinions on Ansible role repository layout
drybjed at drybjed.net
Fri Feb 8 10:36:12 CET 2019
This is a cross-post from a mail of one of the DebOps users, I thought that
others might be interested in the topic.
On Feb 08, Nicolas Quiniou-Briand wrote:
> I will start to share Ansible roles for the PacketFence project on Github
> but I wonder what is the best repository layout for Ansible Galaxy : one
> repo with all roles or one repo per role. I notice that on DebOps project,
> all the roles are located under one repo.
> I just want to know what are the pros, cons and limitations of this
> repository layout from your point of view.
I'm obviously biased, so please keep that in mind.
The choice depends on a few factors. How many roles do you plan to manage at
once? Are they completely independent entities, or do they work together in
some fashion? How many people you have available to maintain them?
You should probably read the mailing list threads in which I talked about
merging DebOps into a single repository:
And here's the afermath of the merge:
I also wrote about this very subject on Reddit:
But pros and cons of each model? Let's see...
Pros of separate git repositories:
- it's easier to hand a role or a few of them to somebody else if you don't
want to deal with them anymore
- separate teams can work on one set of roles independently, each one having
access to specific repositories
- it's a simple publishing model, estabilished by Ansible Galaxy, easy to use
with a limited number of roles (10-20 max, I'd say)
Cons of separate git repositories:
- scales horribly unless you write your own toolset to handle large number of
- lots of overhead when you want to synchronize multiple roles together and
rely on Galaxy to distribute them, because Galaxy uses git tags to handle
versioning. Tags, tags everywhere...
- if you want to use GitHub for issues and pull requests, prepare to deal with
issues and PRs per-repository. There's no good way to centralize it, unless
you create a dummy "issue repository" which only confuses users, and you
still need to deal with PRs per repository anyway.
Pros of a monorepo:
- everything in one place - roles, issues, pull requests, additional tooling,
everything in lockstep. Awesome with a large number of roles.
- you just have to install one git "package" and all of your roles are
available for consumption. You can still use specific roles in playbooks,
there's no downside here.
- git grep over everything. What do you mean, everything? EVERYTHING!
Cons of a monorepo:
- existing tools around Ansible like Molecule are geared towards a single role
per repository model. If you go with a monorepo, you probably will have to
create a custom toolset for it as well, but the problems you have to solve
will be different.
- everything is in lockstep, which might be a problem when you have multiple
teams that want to move at different pace. Scheduling tags/releases based on
time could be a solution to that.
- everyone gets the entire repository / all of the roles. Depending on
preferences or application, that might not be a desirable thing to have.
Ansible Galaxy actually has a very nice support for multi-role repositories
now. I'd say that if you want to start publishing roles from scratch, going
with a multi-role repo is much more benefical. The single Ansible role per
repository was forced on everyone because of limitations of Ansible Galaxy
at the time. It's all better now, go with the monorepo.
Do you mind if I cross-post it to the DebOps mailing list? It might be an
interesting discussion, I wonder how the monorepo looks from the users' side.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 585 bytes
Desc: not available
More information about the debops-users