After PR #862 (1.4.4) made cross-ns Valkey reachable from `sme` ns, the
auth Pod started CrashLoopBackOff with "NOAUTH HELLO must be called with
the client already authenticated". Root cause: bp-valkey 1.0.0 ships
auth.enabled=true (bitnami default) but SME service code + Deployment
templates never plumbed a password through.
Chart 1.4.4 -> 1.4.5. Slot 13 pin lockstep.
Changes:
- core/services/shared/db/valkey.go: add ConnectValkeyWithAuth overload
taking username + password. ConnectValkey kept backwards-compatible
for contabo-mkt's auth-less in-namespace Valkey.
- core/services/auth/main.go + gateway/main.go: read VALKEY_USERNAME +
VALKEY_PASSWORD env, call ConnectValkeyWithAuth when password set,
else fall through to no-auth path.
- NEW templates/sme-services/valkey-cross-ns-secret.yaml: Helm `lookup`
reads bp-valkey's auto-generated `valkey-password` from the
`valkey/valkey` Secret and re-emits it as `sme-valkey-auth` in `sme`
ns. Same pattern as sme-secrets.yaml (#859) and gitea-admin-secret
(#830 Bug 2). On first install the lookup may return nil; Flux's 15m
reconcile picks up the mirror once bp-valkey is Ready.
- auth.yaml + gateway.yaml: add VALKEY_PASSWORD env from `sme-valkey-
auth` Secret with optional=true so contabo-mkt's auth-less path keeps
working when the mirror Secret is absent.
- values.yaml: add `smeServices.valkey.{sourceSecretName,
sourcePasswordKey, destNamespace, destSecretName}` knobs (Inviolable
Principle #4).
Live verified the failure mode on otech103: 11/13 SME pods Running 1/1,
auth in CrashLoopBackOff with NOAUTH HELLO error. Provisioning Pod's
CreateContainerConfigError is unrelated (ghcr-pull, separate ticket).
Co-authored-by: hatiyildiz <hatice.yildiz@openova.io>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fa4395fa3a