Pre-1.0.2 bp-valkey shipped `valkey.auth.enabled: true` (bitnami default) while bp-newapi's REDIS_CONN_STRING default was the passwordless URL `redis://valkey-primary.valkey.svc.cluster.local:6379`. On every freshly-franchised Sovereign the newapi Pod CrashLoopBackOff'd 45x on the Redis ping probe with `NOAUTH Authentication required` — caught on t38 sandbox walk 2026-05-20. This is the Pillar-4 verifier-killing bug for the Sandbox + qwen-code + MCP end-user DoD (#1986). Approach A (simpler, this PR): flip bp-valkey's default to `auth.enabled: false` so the upstream bitnami chart exports `ALLOW_EMPTY_PASSWORD=yes` to the Valkey container. Verified via `helm template` — the render now contains: - name: ALLOW_EMPTY_PASSWORD value: "yes" Other in-cluster consumers tolerate the change: - products/catalyst sme-services (auth.yaml + gateway.yaml) read VALKEY_PASSWORD via `secretKeyRef ... optional: true` and fall back to the no-auth connect path in core/services/shared/db/valkey.go when the value is empty. - products/catalyst projector wraps the password Secret mount in `{{- with .Values.services.projector.valkey.passwordSecret }}` so an absent Secret simply skips the password env var. Approach B (deferred): make bp-newapi mirror the bp-valkey auto-generated password Secret into the newapi namespace and template it into REDIS_CONN_STRING. Larger scope, tracked under #2003 follow-up. Changes: - platform/valkey/chart/values.yaml — auth.enabled: true → false - platform/valkey/chart/Chart.yaml — version 1.0.1 → 1.0.2 - platform/valkey/blueprint.yaml — spec.version + configSchema default - clusters/_template/bootstrap-kit/17-valkey.yaml — chart pin 1.0.1 → 1.0.2 Verified: - `helm dependency build` succeeds (bitnami/valkey 5.5.1 unchanged) - `helm template` renders `ALLOW_EMPTY_PASSWORD=yes` on the Pod - tests/observability-toggle.sh — all 4 cases PASS Closes #2003 Refs #1986 Co-authored-by: hatiyildiz <catalyst@openova.io> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| chart | ||
| blueprint.yaml | ||
| README.md | ||
Valkey
Redis-compatible in-memory cache. Application Blueprint (see docs/PLATFORM-TECH-STACK.md §4.1 — Data services).
Important: Valkey is NOT a Catalyst control-plane component. The Catalyst control plane uses NATS JetStream KV for its own pub/sub + KV needs (see
docs/ARCHITECTURE.md§5 anddocs/GLOSSARY.md—event-spine). Valkey is purely an Application-tier cache for Apps that want Redis-compatible caching. The same upstream technology can serve in multiple categories (per PLATFORM-TECH-STACK §1) — Valkey is on the Application side of that split.
Replication via REPLICAOF (per Application's choice; see docs/SRE.md §2.5).
Status: Accepted | Updated: 2026-04-27
Overview
Valkey provides in-memory caching for sessions, rate limiting, and ephemeral data with multi-region replication support.
As an OSS support provider, OpenOva requires truly open-source components:
- Redis OSS: RSALv2 + SSPL license (since March 2024) - not open source
- Dragonfly: BSL 1.1 license - not open source
- Valkey: BSD-3 license - truly open source
Why Valkey
| Factor | Valkey |
|---|---|
| License | BSD-3 (truly open source) |
| Governance | Linux Foundation |
| Backing | AWS, Google, Oracle, Ericsson, Snap |
| Origin | Fork of Redis 7.2.4 |
| Compatibility | 100% Redis API compatible |
| DR Strategy | REPLICAOF (same as Redis) |
Architecture
Single Region
flowchart TB
subgraph Cluster["Valkey Cluster"]
VK1[Valkey 1]
VK2[Valkey 2]
VK3[Valkey 3]
end
App[Applications] --> VK1
App --> VK2
App --> VK3
Multi-Region DR
flowchart TB
subgraph Region1["Region 1 (Primary)"]
VK1[Valkey Primary]
end
subgraph Region2["Region 2 (DR)"]
VK2[Valkey Replica]
end
VK1 -->|"REPLICAOF"| VK2
App1[Apps R1] --> VK1
App2[Apps R2] --> VK2
DR Strategy: REPLICAOF
Valkey supports Redis REPLICAOF for async replication:
# On DR region Valkey
REPLICAOF valkey.<env>.<sovereign-domain> 6379
# Promote DR to primary (failover)
REPLICAOF NO ONE
| Aspect | Value |
|---|---|
| Replication | Asynchronous |
| Lag | Milliseconds to seconds |
| Consistency | Eventual |
| Failover | Manual promotion |
Configuration
Primary Region
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: valkey
namespace: databases
spec:
replicas: 1
template:
spec:
containers:
- name: valkey
image: valkey/valkey:8-alpine
args:
- --requirepass
- $(VALKEY_PASSWORD)
- --maxmemory
- 2gb
ports:
- containerPort: 6379
env:
- name: VALKEY_PASSWORD
valueFrom:
secretKeyRef:
name: valkey-credentials
key: password
DR Region (Replica)
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: valkey
namespace: databases
spec:
replicas: 1
template:
spec:
containers:
- name: valkey
image: valkey/valkey:8-alpine
args:
- --requirepass
- $(VALKEY_PASSWORD)
- --maxmemory
- 2gb
- --replicaof
- valkey.<env>.<sovereign-domain>
- "6379"
- --masterauth
- $(MASTER_PASSWORD)
Use Cases
| Use Case | TTL | Eviction | DR Needed |
|---|---|---|---|
| Session cache | 24h | LRU | Yes |
| Rate limiting | 1m | Fixed | No (local) |
| API cache | 5m | LRU | Optional |
| Feature flags | 1m | LRU | Yes |
Monitoring
| Metric | Description |
|---|---|
valkey_connected_replicas |
Number of connected replicas |
valkey_replication_lag |
Replication lag in bytes |
valkey_used_memory |
Memory usage |
valkey_commands_processed_total |
Total commands processed |
Migration from Redis/Dragonfly
Valkey is a drop-in replacement:
- No application changes - Same Redis protocol
- Same client libraries - Redis clients work unchanged
- Same commands - Full Redis command compatibility
- Same REPLICAOF - Identical DR pattern
Part of OpenOva