Open jacobbmay opened 1 month ago
Should be fairly easy from a config standpoint, may be painful in upgrade.
The initial configuration settings aren't bad. That said, GitLab needs to know valkey is replicated, and use internal smarts to talk to the write or read nodes based on it's needs. So, need to review the GitLab chart to connect it in right.
GitLab DOES NOT support Redis clusters:
Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.(3k ref arch) Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.(5k ref arch)
It is a bit confusing that they speak of standalone with HA, but based on the settings, I'm guessing they mean what Bitnami's doc on topologies calls "Primary-Replicas with Sentinel". Note that here "Primary" is singular (based on context) and the "HA" would be the read-only replicas.
It'd follow from the Bitnami docs and inference from the Gitlab docs that I must enable the Setinel, always deploy in odd numbers, and tell GitLab about both so it can re-discover the primary node in the event of a fail-over.
Update: needs networking changes to get replication working. Am working on it in the valkey package repo, will propogate changes once proven to work there into the GitLab package's test bundle, validate there, then should be pretty safe to integrate here.
Testing strategy is heavily that it's validated in the application packages, and then should work if there's no smoke in our bundle.
Gitlab 3k user architecture specifies a redis cluster, and starting with 10k architecture it specifies separate cache and persistent redis clusters. We should investigate implementing this with valkey in cluster