MariaDB container is used why still using MySQL naming

[fauust]

MariaDB containers support for now both naming but those are now different project and they have diverged in many aspects. It is possible that those ENV variable will not be supported in the future (probably distant though).

Also, when searching for container images documentation, it helps user to get to https://hub.docker.com/_/mariadb/ instead of https://hub.docker.com/_/mysql/ where there might be differences between how env variables are used or even available to configure the DB.

[CLAassistant]

All committers have signed the CLA.

[murrant]

This is kind of an odd change. We do support MySQL as well. And this actually uses the PHP driver called "mysql".

[fauust]

I know that librenms supports MySQL too, what I find confusing is that in all your examples you use the mariadb:10 image but mix it with MySQL specific namings (mysqld command and MYSQL_ env vars). I don't see how changing those compose examples files would break the MySQL support.

The MySQL PHP connector is compatible with MariaDB but this is not what this change is about.

[murrant]

What is this change about?

FYI, you break everyone's installs with this change...

[fauust]

What is this change about?

This change is about reflecting how you are supposed to configure MariaDB in the container, see https://hub.docker.com/_/mariadb#how-to-use-this-image.

FYI, you break everyone's installs with this change...

How is that??

[murrant]

@fauust user's typically don't rename env variables (or even pay attention to notices that they have been changed) Leaving the new variables unset.

If you want to push the new env variables, forward, you should copy from the old variables to prevent migration pains.

If this does still work with the old variables, that is great, but you didn't touch on that at all so far in your description/comments.

[fauust]

@murrant I am perfectly fine with closing this PR. I thought that those compose files where supposed to be examples and helpers for users willing to install Librenms. It's also motivated by https://mariadb.org/say-the-name-mariadb-mysql-and-the-ecosystem-we-share/ (worth reading if times permits you to).

In that sense I think that it's important to follow upstream documentations and be as precise as possible (and again, using the mariadb:10 image and the mysqld command or MYSQL_ env vars is not wrong but not optimal since it might change in the future and confuse users about what DB they are dealing with).

That said, if there is any chance that this would break current installation or even future deployment, then that's a complete no go also for me.

[murrant]

Yes, it is the .env files that are problematic. I think I need to do something drastic with them.

[crazy-max]

I'm fine with switching the MariaDB container-facing settings to MariaDB naming, especially if we also make the MariaDB tag more explicit. But I don't think we should rename the .env variables in this PR.

Those .env keys are effectively part of the example Compose contract users copy and customize. If someone updates compose.yml but keeps an existing .env with MYSQL_DATABASE, MYSQL_USER, and MYSQL_PASSWORD, Docker Compose will resolve the new ${MARIADB_*} references to empty strings and LibreNMS will start with broken DB credentials.

[murrant]

I realized that the MariaDB containers in the compose files might be too old for these variables. Need to make sure that is not the case before merging this.

@crazy-max I hope people aren't blindly updating compose files. Generally I don't do that in practice.

[fauust]

I realized that the MariaDB containers in the compose files might be too old for these variables. Need to make sure that is not the case before merging this.

@murrant this is the commit that introduced the new MARIADB_* vars: MariaDB/mariadb-docker@9005157 so it's 5 years old, from what I see on stats.librenms.org, there might still be deployment with 10.0 that did not had them, not sure. But I am also not sure when you default to mariadb in the compose examples.