Consider the Valkey version in the Admin dashboard

Summary

GitLab now supports Valkey instead of Redis in Beta: Add support for Valkey backend in Redis and Sen... (omnibus-gitlab!9113 - merged).

The admin dashboard should take into consideration the Valkey version, not only the Redis version.

Steps to reproduce

  1. Install Omnibus GitLab 18.9
  2. Enable Valkey (version is 7.2.11)
  3. Go to the admin panel and you'll see the Redis version instead of the Valkey version.

What is the current bug behavior?

Dashboard shows redis_version (7.2.4) not valkey_version.

What is the expected correct behavior?

Admin dashboard should show 7.2.11 instead of 7.2.4.

Relevant logs and/or screenshots

Check the valkey server version on your VM:

# /opt/gitlab/embedded/bin/valkey-server --version
Server v=7.2.11 sha=97b6663c:0 malloc=jemalloc-5.3.0 bits=64 build=13db84612d38d6d8

redis

Output of checks

This bug should happen on GitLab.com. But we haven't enabled Valkey yet.

Possible fixes

I believe the problem is the following:

On the app/controllers/admin/dashboard_controller.rb we call: @redis_versions = Gitlab::Redis::ALL_CLASSES.select(&:active?).map(&:version).uniq.

The $:version likely gets resolved by some redis gem we use to connect to redis and take its version from the INFO server redis command which, when valkey is enabled, it returns:

root@gitlab-3k-test-redis-1:/var/log/gitlab/redis# gitlab-redis-cli INFO server
# Server
redis_version:7.2.4
server_name:valkey
valkey_version:7.2.11
...

I believe our ruby gem is taking redis_version:7.2.4, without acknowledging that Valkey might be enabled, and the version should be taken from valkey_version:7.2.11 instead.

The Valkey repository states upstream:

We will introduce 2 new info fields.
valkey_version:7.2.4: This will indicate the valkey_version compatibility.
redis_version:7.2.4: this isn't new, just called out that we will leave it for compatibility.
server_name:valkey: This will provide a way for external clients to determine that this is valkey, if they want.

So I think we have 3 options:

  1. Contribute upstream to make .version from our current redis gem acknowledge server_name to know where to take the version from.
  2. Move to another redis client gem that supports server_name.
  3. Implement our own custom logic to fetch the version by sending an INFO command to redis ourselves, then parsing the server_name to decide where to take the version from.