Add valkey/redis driver with operator-secret auto-configuration #3

2026-08-23T16:37:30+10:00

unkin-agent commented

2026-08-23 16:37:30 +10:00

Why

Apps fronted by valkey-operator instances need the same wait-for-ready initContainer that postgres workloads already get, and wiring per-field secretKeyRefs for operator-generated secrets is boilerplate in every workload. waitfordb now checks valkey/redis readiness and natively understands the secret shapes CNPG and valkey-operator generate, so an initContainer is just envFrom plus a mode variable.

Changes

Adds a valkey driver (alias: redis): fresh TCP connection per attempt, optional AUTH (ACL user or default user), then PING, reusing the existing retry/backoff wait loop; accepts redis:///valkey:// DSNs; default port 6379; no new dependencies (minimal RESP client)
Adds WAITFORDB_SECRET_FORMAT=cnpg|valkey for operator secrets injected wholesale via envFrom: CNPG <cluster>-app host/port/dbname/user/password keys, and valkey-operator key-per-username secrets (authenticates as _operator when present, or as WAITFORDB_USER with the password taken from the same-named key; shapes verified against the live jellyfin secrets, keys only)
Autodetects the format from the injected keys (CNPG keys -> postgres, valkey keys -> valkey); explicit WAITFORDB_DRIVER/WAITFORDB_* always win, and the PG* fallback plus all existing flags behave unchanged
Allows valkey configs without user/database (unauthenticated PING is valid); keeps passwords out of logs including the new paths
Tests: secret shape parsing/autodetect/driver-mismatch/precedence, a fake RESP server covering NOAUTH/WRONGPASS/ACL auth/DSN parsing, and a retry-until-up wait test; go test -race, vet, gofmt clean
README: envFrom initContainer snippets for CNPG and valkey-operator, env-table and usage updates

## Why Apps fronted by valkey-operator instances need the same wait-for-ready initContainer that postgres workloads already get, and wiring per-field `secretKeyRef`s for operator-generated secrets is boilerplate in every workload. waitfordb now checks valkey/redis readiness and natively understands the secret shapes CNPG and valkey-operator generate, so an initContainer is just `envFrom` plus a mode variable. ## Changes - Adds a `valkey` driver (alias: `redis`): fresh TCP connection per attempt, optional AUTH (ACL user or default user), then PING, reusing the existing retry/backoff wait loop; accepts `redis://`/`valkey://` DSNs; default port 6379; no new dependencies (minimal RESP client) - Adds `WAITFORDB_SECRET_FORMAT=cnpg|valkey` for operator secrets injected wholesale via `envFrom`: CNPG `<cluster>-app` `host`/`port`/`dbname`/`user`/`password` keys, and valkey-operator key-per-username secrets (authenticates as `_operator` when present, or as `WAITFORDB_USER` with the password taken from the same-named key; shapes verified against the live jellyfin secrets, keys only) - Autodetects the format from the injected keys (CNPG keys -> postgres, valkey keys -> valkey); explicit `WAITFORDB_DRIVER`/`WAITFORDB_*` always win, and the `PG*` fallback plus all existing flags behave unchanged - Allows valkey configs without user/database (unauthenticated PING is valid); keeps passwords out of logs including the new paths - Tests: secret shape parsing/autodetect/driver-mismatch/precedence, a fake RESP server covering NOAUTH/WRONGPASS/ACL auth/DSN parsing, and a retry-until-up wait test; `go test -race`, `vet`, `gofmt` clean - README: `envFrom` initContainer snippets for CNPG and valkey-operator, env-table and usage updates

unkin-agent added 1 commit 2026-08-23 16:37:30 +10:00

Add valkey/redis driver with operator-secret auto-configuration

ci/woodpecker/push/test Pipeline was successful

Details

ci/woodpecker/push/build Pipeline was successful

Details

ci/woodpecker/pr/build Pipeline was successful

Details

ci/woodpecker/pr/test Pipeline was successful

Details

ci/woodpecker/push/pre-commit Pipeline was successful

Details

ci/woodpecker/pr/pre-commit Pipeline was successful

Details

a466b3e07f

Apps fronted by valkey-operator instances need the same wait-for-ready
initContainer postgres workloads already get, and wiring per-field
secretKeyRefs for operator-generated secrets is boilerplate. waitfordb
now speaks enough RESP to AUTH and PING, and natively understands the
secret shapes CNPG and valkey-operator generate so an initContainer is
just envFrom plus a mode variable.

- valkey driver (alias: redis): fresh TCP connection per attempt,
  optional AUTH (ACL user or default), PING, reusing the existing
  retry/backoff wait loop; redis:///valkey:// DSNs; default port 6379
- WAITFORDB_SECRET_FORMAT=cnpg|valkey for envFrom-injected operator
  secrets: CNPG <cluster>-app host/port/dbname/user/password keys, and
  valkey-operator key-per-username secrets (_operator preferred, or
  WAITFORDB_USER's same-named key)
- autodetection from injected keys (CNPG keys -> postgres, valkey keys
  -> valkey); explicit WAITFORDB_DRIVER/WAITFORDB_* always win, PG*
  fallback and all existing flags unchanged
- valkey needs no user/database to be valid (unauthenticated PING)
- tests: secret shape parsing/autodetect/mismatch, fake RESP server
  covering NOAUTH/WRONGPASS/ACL auth/DSN, retry-until-up wait
- README: envFrom initContainer snippets for CNPG and valkey-operator

benvin merged commit 39b2195f5a into main

2026-08-23 17:02:13 +10:00

benvin deleted branch benvin/valkey-support

2026-08-23 17:02:14 +10:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unkin/waitfordb#3