feat: check database version compatibility #3310
Conversation
A new method, 'check_version_compat()', takes 2 arguments: min and
deprecated.
Given that 'init()' has been called and a version number is now part of
the instance's attributes, this function will compare its arguments to
it.
Version numbers are compared with the 'version.lua' module at:
https://github.com/Kong/version.lua
- When the current version is above 'min', we succeed.
- When the current version is below 'min'
- If 'deprecated' is given, and the current version is above it,
a deprecation warning is logged.
- Otherwise, we error, since the current version is below the
minimum recommended, and below the oldest deprecated version.
As of 0.12.3: PostgreSQL - current minimum recommended: 9.5 - deprecated: 9.4 Cassandra - current minimum recommended: 2.2 - deprecated: 2.1 Versions below MIN and DEPRECATED will result in an error.
|
Should there be some way to start Kong in case the version is below the oldest deprecated one. I mean I would not want to end up with situation with many old Windows software installers that just refuse to install because of a faulty check (even if the software was just fine with newer version of Windows). Also there might be PostgreSQL / Cassandra compatible client interface in some other databases that just report something different as a version (and limiting someone trying those seems to add very little). |
I would be wary of potentially corrupting the database, but well, if the option is obvious enough that it implies danger, why not, we could.
Good point, especially with implementations like ScyllaDB. Maybe a |
@bungle we would run into that if we were checking for a maximum version, but for minimum that is unlikely to happen.
It is a valid point, indeed, but personally I'd rather avoid the additional "moving part" of such a dangerous flag. For Kong CE, the adventurous user can always edit |
| end | ||
|
|
||
| local db_v = version.version(db_infos.version) | ||
| local min_v = version.version(min) |
There was a problem hiding this comment.
you can update the 'version.lua' library to 1.0 and change those into version(min) without the double 'version' name
There was a problem hiding this comment.
Yes, I saw; but as usual when possible, we'll make that a separate contribution
thibaultcha
added
pr/ready
This fixes a regression introduced in #3310. If the database is unreachabel when Kong start, it is our policy that the error message be prefixed with `[postgres error]` (in the case of PostgreSQL) to help the user troubleshoot the issue. Prior to this patch, this behavior was changed in #3310, since it introduced a call to `init()` in the CLI. Users would see: ``` $ kong start Error: connection refused ``` Instead of: ``` $ kong start Error: [postgres error] could not retrieve server_version: connection refused ```
This fixes a regression introduced in #3310. If the database is unreachabel when Kong start, it is our policy that the error message be prefixed with `[postgres error]` (in the case of PostgreSQL) to help the user troubleshoot the issue. Prior to this patch, this behavior was changed in #3310, since it introduced a call to `init()` in the CLI. Users would see: ``` $ kong start Error: connection refused ``` Instead of: ``` $ kong start Error: [postgres error] could not retrieve server_version: connection refused ``` From #3411
Add a check to the DAO's
init()method to ensure the compatibility of the underlying database (PostgreSQL or Cassandra). This check is ran:kong startcommandinit_by_luaWe support "minimum recommended version", and an optional "oldest deprecated version", which as of today and 0.12.3 are:
PostgreSQL
Cassandra
When using a deprecated datastore, the CLI shows:
It is also shown in the nginx logs when starting Kong from
nginx(e.g. Docker images).When using a version that is below the minimum recommended, and below the oldest deprecated one, we error out from the CLI (and from
init_by_lua):