Should ansible.mysql be split into separate MySQL and MariaDB collections?

Project Discussions
, , ,
1

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.

2

Collection slilt does not imply repository split.

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.

1 Like
3

@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.

1 Like
4

I’m undecided:

  • 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 :frowning:

5

A very good question.

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 :slight_smile:

@kks that would be a good solution for two collections, except for two points:

  1. 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 :wink: .)
  2. 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).