RFC: drop sqlite3/mysql support for all bareos versions
Closed this issue · 11 comments
bareos 21 has dropped support for the sqlite3 and mysql db drivers, leaving postgres as the only supported db. mysql/sqlite3 support has been deprecated since bareos 19.2. As of #124, 19.2 is the oldest version supported by this module.
https://www.bareos.com/end-of-life-mysql/
The docs say that the Db Driver
configuration value is also deprecated.
https://docs.bareos.org/Configuration/Director.html#config-Dir_Catalog_DbDriver
My preference would be to remove the baseos::director::catalog::db_driver
parameter completely instead of trying to validate parameters differently based on the bareos version string. The question is is anyone is using this module with sqlite3/mysql and bareos 19.2 or 20?
/CC
@smortex
@hugendudel
@kenyon
@FlorentPoinsaut
@aaronreay
@benibr
@matejzero
@wardhus
@crazymind1337
I believe we need to resolve the bareos 21 compatibility issue before we ship a new major release, which was being prepared as #121. If anyone has an objection to removing sqlite3/mysql support, please say so on this ticket. Conversely, if you have /no objection/ to removing said support, it would be appreciated if you could also touch this ticket saying it isn't a concern for you.
Hey folks,
I would tend to change the dafault back again to 20 and leave a nitice+notify for at least one release?
Harm
On the other hand, one could have read therelease notes?
I don't think we should be afraid to make breaking API changes, especially if no one objects.
Yes agree, but it is about backup hehe
Another option would be to drop support for < 21.
Data types would make the breaking change more obvious for users I guess, but I would not update a major release of such a module without reading the ChangeLog thoughtfully 🤔
A compilation failure unless the user explicitly say they want to use PostgreSQL looks reasonable to me: users who put things in hiera would have bad surprises if we just remove parameters they have set to some non-supported value (no issue in that case for people not doing this since using a non-existant parameter raise an error).
We are using Postgres in our production, so no need for MySQL or SQLite.
We are using Postgres in our production, so no need for MySQL or SQLite.
Same here.