Repository navigation
fix(valkey): pin the opt-in Valkey cache to 9.1.2-alpine - #1370
Merged
Merged
Conversation
dylan-openhands
approved these changes
Oct 8, 2026
aivong-openhands
marked this pull request as ready for review
October 9, 2026 11:08
Contributor
|
🚀 Released in openhands/0.80.0. |
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.
Why
The opt-in Valkey cache backend (the
valkeysubchart, chart 0.11.0) runsvalkey/valkeyat the subchart's appVersion,9.1.1on Debian, becausevalues.yamlsets no tag. Trivy reports 3 critical / 15 high findings with fixes available on that image. This setsvalkey.image.tagto9.1.2-alpine, the current 9.1 patch on the Alpine base, which has 0 critical / 0 high. The Debian9.1.2build is not enough on its own: it still has 5 fixable high OpenSSL/PCRE2 findings, which is also why bumping the subchart to 0.12.0 (appVersion 9.1.2) would not clear them. Valkey staysenabled: false, so default installs render nothing different.Validation
valkey/valkey:9.1.1reports 3 critical / 58 high (3 / 15 fixable);9.1.2-alpinereports 0 critical / 0 high.valkey:values and aredisSecret, came up ready with no restarts on9.1.2-alpine(main and init containers). The init container built the ACL file from the existing Secret; unauthenticated and wrong-password commands gotNOAUTH; authenticatedPING,SETandGETworked; and another pod reached it through theoh-valkeyService.helm lintpasses withvalkey.enabled=true. Withredis.enabled=falseandvalkey.enabled=true, all three Valkey image references render9.1.2-alpineand the app'sREDIS_HOST/REDIS_PORTresolve tooh-valkey:6379. A default render contains no Valkey image.Helm Chart Checklist
dataStorage.enabled: false), so the upgrade is a pod restart on the new image.valkey.image.tagstill wins.This PR was drafted by an AI agent on behalf of the user.