Repository navigation
redis: keep config checksum stable across chart versions - #989
Merged
Merged
Conversation
The redis Deployments' checksum/redis-config annotation hashed the whole rendered ConfigMap, including its helm.sh/chart and app.kubernetes.io/version labels. With config.enabled, every Sourcegraph upgrade changed the hash and restarted redis-cache and redis-store even when redis.conf was unchanged. Move the redis.conf rendering into a sourcegraph.redis.conf helper that both the ConfigMaps and the checksum use, so the checksum covers only redis.conf. Amp-Thread-ID: https://ampcode.com/threads/T-01a18a84-419f-703b-a77d-635921732235 Co-authored-by: Dinesh Kumar <dinesh.kumar@sourcegraph.com>
The checksum tests pinned a hash for redis-cache only, so a regression confined to redis-store would not have failed them. The cases also sat in redisConfigMount_test.yaml, which covers the volume mount rather than the annotation. Move them into a redisConfigChecksum_test.yaml suite, pin a hash for both services, and assert the hash ignores unrelated input (global labels, image tag) while still changing for maxmemory, maxmemoryPolicy and additionalConfig. The helper now fails the render when a vendored redis.conf is missing instead of silently hashing an empty body.
devdinu
marked this pull request as ready for review
October 30, 2026 20:38
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With
redisCache.config.enabled/redisStore.config.enabled, redis-cache and redis-store restart on every Sourcegraph upgrade, even whenredis.confand the redis images are unchanged. Sourcegraph Cloud enabled this fleet-wide on 2026-09-27 (sourcegraph/cloud#64455), and since then every deployment has restarted redis despite the frozen redis image tags.Cause
The
checksum/redis-configpod annotation hashed the whole rendered ConfigMap:That rendering includes the
helm.sh/chart: sourcegraph-<version>andapp.kubernetes.io/versionlabels. The chart version is bumped with every Sourcegraph release, so the hash changed every upgrade, the pod template changed, and theRecreatestrategy restarted redis.Fix
Move the
redis.confrendering (vendored file plusmaxmemory,maxmemory-policy,additionalConfig) into asourcegraph.redis.confhelper. The ConfigMaps render their data from it, and the Deployments hash only its output. Redis now restarts only when its configuration changes, such as a memory limit change that resizesmaxmemory.Upgrading to a chart with this fix changes the annotation value once, so redis restarts one last time on that upgrade.
Checklist
ref PLAT-910
Test plan
helm unittest charts/sourcegraph: 209/209 pass. The new cases inredisConfigMount_test.yamlassert the checksum is identical at chart versions 8.0.0 and 9.9.9 and changes whenmaxmemorychanges; the two version cases fail against the old templates.helm templatebefore and after for defaults, all overrides (includingtplinadditionalConfig), no memory limit,localDevMode, andexistingConfig: rendered ConfigMaps are byte-identical; only the checksum values differ.redis.conftext, computed independently.