2 Commits

Author	SHA1	Message	Date
NanHan Qing	6c2042a043	fix(helm): give each Secret pair one precedence chain (#7291) ... * refactor(helm): derive the postgres Secret name from one helper `databaseUrlSecret` re-encoded the `postgresql.external.existingSecret` then `postgresql.existingSecret` chain in its own `if`/`else if`. Three consumers read it — the gateway's `DATABASE_URL`, the postgres StatefulSet's `POSTGRES_PASSWORD`, and `postgres-secret.yaml`'s own `metadata.name` — so a source added to one helper and not the other would make the gateway and the StatefulSet resolve different Secrets. That is the class of bug #7149 fixed for the redis pair. Extract `databaseUserSecret` as the single encoding of the chain and let `databaseUrlSecret` fall back to the chart-managed name when it is empty, mirroring `redisUserSecret` / `redisUrlSecret`. Pure refactor: the rendered manifest is byte-identical before and after across the four configurations (chart-managed, `existingSecret`, `external.existingSecret`, and both set), compared with `helm template`. Adds `test_helm_database_secret_precedence.py`, which pins that both consumers name the same Secret and that only the chart-managed branch renders a Secret. Dropping either precedence source fails the two cases that depend on it. Suggested in review of #7161. * fix(helm): keep the postgres Secret helper's truthiness Review follow-up on the previous commit. Two things were still wrong: `postgres-secret.yaml` kept its own copy of the precedence chain for the render gate, so "the only place the chain is encoded" was not yet true — a source added to `databaseUserSecret` alone would have left that gate empty and rendered an unreferenced `<release>-postgres` Secret. It now reads the helper, like `redis-secret.yaml` already did. `or` returns its last operand even when it is falsy, so `postgresql.existingSecret: false` (how people spell "not set") named the Secret `false` instead of falling back to the chart-managed one. Chaining `default` keeps the old if/else-if truthiness and yields an empty string for any falsy value; the gateway's `$pgConfigured` now reads the same helper rather than re-listing the two keys. Two falsy cases join the parametrize list: `false` in the lower-precedence slot and in both slots. Both fail against the previous `or` version with `assert [] == [False]` — the Secret literally named `false` — so they are regressions this test can actually catch. The other four configurations render byte-identically before and after. * fix(helm): keep the redis user-Secret helper's truthiness Same defect the postgres helper had, one release later: `redisUserSecret` used `or`, which returns its last operand even when falsy, so `redis.existingSecret: false` named both the gateway's `redis-url` ref and the StatefulSet's `redis-password` ref after a Secret called `false`. The render gate in `redis-secret.yaml` saw the string "false" as truthy, so it skipped creating the chart-managed Secret — leaving two dangling refs and a StatefulSet that cannot start. `default` chaining restores the pre-`redisUserSecret` if/else-if behaviour: any falsy value yields an empty string, so the chart-managed branch is taken. `redisConfigured` now reads the helper instead of re-listing the two keys, matching the gateway's `$pgConfigured`. Verified against the four string-valued configurations (chart-managed, `existingSecret`, `external.existingSecret`, both): renders are byte-identical before and after. The two new falsy cases fail on the previous version, and `--basetemp` makes all 14 cases in this file pass. * docs(helm): drop a stray article in the helper comment	2026-10-23 00:26:48 +08:00
NanHan Qing	493178dd86	fix(helm): honor redis-password from a user-managed Secret (#7161) ... * fix(helm): honor redis-password from a user-managed Secret The bundled Redis StatefulSet derived its AUTH mode only from `redis.auth.password`, so a `redis.existingSecret` that carried both `redis-url` and `redis-password` left the gateway authenticating against a server started without `--requirepass`. Both probes used the no-auth path as well, so the Pod reported healthy while the gateway could not connect to it. Whether a user-managed Secret carries `redis-password` is only knowable at runtime, so the key is now read with `optional: true` and the entrypoint enables AUTH only when the value is nonempty. A Secret carrying only `redis-url` keeps the no-auth behavior instead of failing to start, and a stale `redis.auth.password` no longer wins over the selected Secret, matching what values.yaml documents. Refs #7149 * test(helm): cover Redis Secret authentication and share resolution Add the issue #7149 render-and-shell regression suite for chart-managed, user-managed and external Redis credentials. Resolve Secret precedence once for the Gateway, bundled server and chart-owned Secret, and clarify how optional user-managed passwords select AUTH at runtime. Regression coverage adapted from dakjdakd's commit 7e20745d678276ed33e8f8eafd2c576fa8ae9aec. Co-authored-by: dakjdakd <1428823446@qq.com> * test(helm): assert the stale value instead of an unused constant `test_bundled_redis_uses_optional_existing_secret_password` checked the module-level `PASSWORD` constant against the rendered manifest, but that constant is never an input to any of its six renders — the parametrized value is `ignored_password`. The guard could therefore never fail, so a template edit that started rendering `redis.auth.password` alongside a user-managed Secret would have gone unnoticed. Assert the parametrized value instead: it is the stale input the case is meant to keep out of the manifest. Verified the value is detectable in a render that does carry it (the chart-managed path renders it twice), so the assertion is no longer vacuous. Also fix the garbled sentence in `tests/AGENTS.md` that described this coverage as "stale values passwords". --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com> Co-authored-by: dakjdakd <1428823446@qq.com>	2026-10-22 15:41:46 +08:00