I’m one of long-term maintainers of ansible.mysql (recently renamed from community.mysql — same codebase, same collection). This post is to open a discussion about whether it makes sense to split the collection into two: one focused on MySQL, one focused on MariaDB. I don’t have a strong position yet — would be great to get some input from other maintainers and users before forming one.
MySQL and MariaDB are diverging
MariaDB was forked from MySQL in 2009. Since then, they have evolved into distinct database systems with different philosophies, feature sets, SQL syntax, and even tooling.
Some examples of how this divergence surfaces in the collection today:
Replication SQL: commands like SHOW MASTER STATUS, SHOW SLAVE STATUS, and CHANGE MASTER TO were renamed — but differently in each system and at different version thresholds.
Roles: MariaDB stores role mappings in mysql.roles_mapping; MySQL uses mysql.role_edges. The WITH ADMIN OPTION clause exists only in MariaDB.
Authentication plugins: mysql_native_password was removed in MySQL 9.7+; MariaDB still supports it. The two systems also use different default authentication methods and hash algorithms.
Features unique to one side: temporal tables exist in MariaDB but not MySQL; MySQL has Group Replication, which MariaDB does not.
Maintenance implications
The collection already handles these differences through separate implementation modules (implementations/mysql/ and implementations/mariadb/), version-specific SQL command resolution, and scattered conditional branches throughout the code. Every new feature or bugfix that touches an area where the two systems differ requires implementing and testing it twice — once per system. Additionally, features that exist in one system but not the other require guard code and explicit documentation of the limitation. As the two systems continue to diverge, this overhead is likely to grow.
The case for a split
Maintaining separate collections (ansible.mysql and a new community.mariadb) could allow each to evolve independently — adding system-specific features without compromise, writing cleaner code without cross-system conditionals, and targeting integration tests precisely at the relevant database versions. A MariaDB-focused collection could also align more naturally with MariaDB-specific tooling and SQL extensions without carrying MySQL compatibility concerns.
The case against a split
A significant portion of the codebase is still relevant to both systems — connection handling, general query utilities, privilege management basics, and more. Splitting would mean maintaining two copies of this shared logic. Bugfixes to one collection would need to be manually identified and backported to the other, and vice versa. This coordination overhead could outweigh the benefits, especially given the current maintainer capacity. It would also split the contributor community, making it harder to attract and retain contributors to either project.
Questions for the community
What do you all think?
Is the divergence already causing you pain as a user or contributor?
Would you be willing to contribute to a dedicated MariaDB collection if one existed?
Are there approaches to the shared-code problem that we haven’t considered?
Any experience, opinion, or data point is welcome.
I am proponent of following repo structure:
REPO_ROOT/ansible_collections/namespace/collection_name/galaxy.yml
This allows to have two (or several collections) in one repo:
./ansible_collections/ansible/mysql/galaxy.yml
./ansible_collections/community/maria/galaxy.yml
This repo structure has many benefits one of which is that is not possible to install collection directly from github repo.
Common code can be softlinked to respective files.
@kks thanks for the option! Though, the MariaDB and MySQL parts are intertwined a lot via conditions in many places in the code because of historical reasons and their slow divergence..
So maybe repo separation and gradual clean up at this stage would work better. Not sure.
On one hand, I’m for a split because every PR is a nightmare of complexity due to the math engine x version. Removing engine from the equation would simplify things. Additionally, every new feature added on one side will tilt the balance even more.
On the other I’m against the split because : I’m unsure the community has the time to do the split and contribute to both collections. I know I don’t
My main argument against a split is that it would be stretching maintainers more thin. A certain amount of work will be identical for both collections, so having two split repositories means having to duplicate each such change for the other repo. It also means two collections that needs release management.
Besides that, I’m neutral. I’d only use community.mariadb in case the split happens
@kks that would be a good solution for two collections, except for two points:
Zuul likely won’t handle this. (This could/should also be seen as yet another reason why we should get rid of Zuul for community collection publishing ASAP .)
You’d be forced to keep versions in sync, since a version tag would apply to both versions. So if a MariaDB only feature is added and should trigger a release, there will also be an ansible.mysql release with the same version number, even if it doesn’t contain any change.
Mainly for reason 2 I don’t think this is a good idea in general, and also specifically for a.mysql and c.mariadb (except for very tightly coupled collections).
For second point, I do not see a problem - I’ve personally implemented release of two collections with the same FQCN out of the single repo. Different collection versions for instance - galaxy-x.y.z and aap-x.y.z are published independently with repo tagged as well. I would like to point out that when content is released version should come first and only after repo tag should be created, not vice versa (common approach for ansible collections). In that case one can release as many collections from one repo with correct tags, etc.
The only way to publish community.* collections right now is through Zuul. You push a tag X.Y.Z to the collection repo, and Zuul will publish the collection built from that tag as X.Y.Z on Galaxy.
That doesn’t work when every collectoin release must be tagged with a tag named X.Y.Z or vX.Y.Z. Also having two independent colletions in one repository makes it unnecessary hard to juggle with stable release branches.
I think the big question here is if it’s easier to maintain a collection that tries to cater for both MySQL and MariaDB, or two collections that specialize on one or the other.
But I’m not involved there, so I can’t answer this
For the sake of backward compatibility, it would be much better if community.mysql was replaced by just one collection for which we could have runtime redirects. If there is one replacement collection for mysql and another for mariadb, it makes things more complicated for users. And I’m also not sure how this would impact the Ansible package where we already have a community.mysql → ansible.mysql redirect in place.
I understand if maintaining one collection is not practical anymore given differences between the two server implementations, although I’m not sure that maintaining two separate collections is necessarily less work.
Thanks for your opinions, folks - lots of fair points!
As one of the longest involved maintainers (~7 years), i can say that it was always a pain to handle code there, unit, and especially integration tests, but it’s getting very noticeably more and more painful. I’m feeling it now when adding the latest MySQL LTS to it… that’s why I started this topic.
I would split them.
If there’s support for this initiative, I personally can commit to:
splitting the collection (well, it’ll be just a fork)
deprecating MariaDB support in ansible.mysql (announcements, warnings everywhere when MariaDB is used).
releasing and publishing community.mariadb, inviting potential maintainers
gradually tidying up tests and code, making it more organized
inviting, promoting, and mentoring new maintainers there
Of course, anything can change (get hit by a bus or whatever), so there’s some risk. I’ll add my team contacts to its README, so if someone wants to take care of the collection, my team is always open to discussion about giving permissions.
Let’s discuss this topic a bit longer and vote if needed.
announce MariaDB support deprecation in ansible.mysql, add warning, etc.
schedule dropping the support for the next major release, but not earlier than in 6-12 months from now (I’ll backport stuff back and forth during that period if needed).
All the points from both sides are fair and its not a trivial decision.
2 points I can add that are for the split:
New users that are searching for a collection that is specific to mariadb might miss this collection. Googling mariadb Ansible collection does bring you up this collection but the title is specific to mysql and it can mislead (I know description does mantion mariadb though).
As time passes and features diverge and become more specific to every collection, it will be harder and harder to maintain both in the same collection. There won’t be a better time in the future.
As everyone mentioned already - this is a tough one indeed.
At this point, where MariaDB has fully renamed all their binaries and given only growing divergence between these two - it would make total sense to split modules and not carry extremely complex logic and usecases from both worlds.
I am not that afraid of the argument of spreading too thin, as eventually it will become easier to review and maintain. But also MySQL/MariaDB have different lifecycle anyway, so it can be balanced well enough I guess.
I am more afraid of the user perspective though. Because as an operator you usually don’t know what you’re dealing with as a backend. Most software still works with both MySQL/MariaDB interchangeably.
So logic of detecting which server you’re running against should be offloaded to roles/playbooks. And this might not be that trivial task to do at the moment.
I wonder if some kind of “detect_engine” module should be introduced with the split to address that, and allow to do dynamic include/blocks depending on that.
Without going into too much philosophy, I think this boils down to how much of the code (of the collection) or functionality is the same between MySQL and MariaDB. For example, if they share 80% of the code/functionality and only 20% of the code covers differences, it does not make much sense for a split. Opposite would be true if the situation was reversed.
Some differences would always be present even between versions of the same solution. So in essence, supporting both solutions is like supporting even more versions of the same solution. And that’s just a reality we have to live in.
Splitting, as @felixfontein already said, will just double the work an dilute already thin number of maintainers and contributors.
I’ve been following this discussion closely, and I strongly agree that splitting mysql and mariadb into dedicated collections is the right move forward.
The two databases have diverged significantly enough to warrant this split.
I would love to step up, take ownership, and drive the maintenance of the community.mariadb collection.
Having previously made contributions to Ansible roles and other modules (mostly within ansible.aws & community.aws), I feel ready to take on this challenge.
My goal is not just to maintain the code, but to actively build and bootstrap a small, dedicated community around MariaDB automation.
I am fully prepared to do the heavy lifting to get this moving, but I would love to collaborate with anyone else interested in this split.
To that end, I have already reached out to a key expert from the MariaDB ecosystem to see if we can rally more collaborators and technical backing.
We announced that we’d keep the community.mysql → ansible.mysql redirect until Ansible 17, so it’d be good if that still worked with mariadb until Ansible 16’s EOL in another year and a half, unless we want to change the community.mysql deprecation period or pin ansible.mysql in the ansible package or maintain an additional stable branch of ansible.mysql that still supports mariadb.
I think this is a very good point to consider as well.
Also, I saw you mentioned that testing is particularly problematic. What is the main difficulty there? Is there some improvement to the test infrastructure that could make this easier? I know felixfontein has done a lot of work in GitHub - ansible-community/antsibull-nox: Antsibull nox helper · GitHub to simplify/automate testing and CI infratructure for collections.
@gotmax23 Thanks for the clarification on the package and the question! If we go down the splitting road, we’ll keep the compatibility for 1.5 year (no problem as we’ve been doing it since time immemorial).
To the question about testing: Lots of conditions and paths in the code caused by more and more differences between the two, which leads to more and more conditions in the tests let alone more complicated infra setup handling.
Despite overlap, they are actually different RDBMSes that are drifting apart rather than getting any closer.
@eRadical thanks for your interest! We’ll be happy to make you its maintainer.
Let’s vote then (will keep the poll open until June 25, 2026).
Do we want to fork community.mariadb from ansible.mysql and continue MariaDB specific development in community.mariadb? Compatible fixes will be backpored between the collections and ansible.mysql will support MariaDB for at least December 31, 2027.
Yes
No (continue as is)
Abstain (not involved neither as ansible.mysq maintainer nor its user)
0voters
Folks, please vote
UPDATE: I should’ve made the Abstain option w/o that comment - now it sounds like you can’t vote yes/no if you’re not involved - it’s not true, sorry. Please ignore and vote as you like.
.)