You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(helm): deliver bundled REDIS_URL via ConfigMap so an operator value always wins
Injecting REDIS_URL as an inline container env made it beat every envFrom
source, so a REDIS_URL held in a pre-created Secret or synced by External
Secrets was silently shadowed and traffic moved to a fresh in-cluster Redis.
Kubernetes resolves duplicate envFrom keys by letting the last source win, so
the bundled URL now ships as a ConfigMap listed before the app Secret. Any
operator-supplied value overrides it without the chart needing to read it,
which also removes the redis.provideUrl flag the previous attempt required.
`app.env.REDIS_URL` takes over whenever it is set, and the chart skips the bundled instance so you do not get a stray pod.
61
+
`app.env.REDIS_URL` takes over whenever it is set, and the chart skips the bundled Deployment so you do not get a stray pod.
62
62
63
-
If the URL lives in a secret store rather than in values:
64
-
65
-
- **External Secrets** — map `externalSecrets.remoteRefs.app.REDIS_URL`. The chart detects the mapping and steps aside automatically.
66
-
- **Pre-created Secret** (`app.secrets.existingSecret`) — set `redis.provideUrl: false`. The chart cannot read your Secret, so without this it would inject a computed `REDIS_URL` that takes precedence over `envFrom` and shadows your value.
63
+
If the URL lives in a secret store instead — a pre-created Secret or one synced by External Secrets — it also wins, and there is nothing extra to configure. The bundled URL is delivered as a ConfigMap listed before the app Secret in `envFrom`, and Kubernetes lets the last source win for duplicate keys, so your value overrides it without the chart ever reading it.
67
64
68
65
The bundled Redis is deliberately non-persistent (`--save ""`, `--appendonly no`) with a 512 MB cap: Sim stores coordination state and short-lived keys in it, so a restart costs in-flight live updates rather than committed data.
Copy file name to clipboardExpand all lines: helm/sim/README.md
+3-9Lines changed: 3 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -473,17 +473,11 @@ Two changes alter behavior on an existing release. Neither requires action, but
473
473
474
474
* **Free-tier plan limits are no longer preset.** `app.envDefaults` previously shipped `RATE_LIMIT_FREE_SYNC`, `RATE_LIMIT_FREE_ASYNC`, `EXECUTION_TIMEOUT_FREE`, `EXECUTION_TIMEOUT_ASYNC_FREE`, `FREE_TABLES_LIMIT: 3`, and `FREE_TABLE_ROWS_LIMIT: 1000`. With billing disabled the application treats these as **opt-in** — unset means unlimited — so presetting them imposed hosted-plan caps on self-hosted deployments and diverged from Docker Compose, which presets nothing. They are now commented out. **On upgrade, these limits stop being enforced.** To keep them, set the keys explicitly under `app.env`. An explicitly set value has always taken precedence and is unaffected.
475
475
476
-
* **Redis is now bundled** (`redis.enabled: true`), matching the Docker Compose stack. Redis backs pub/sub and the Socket.IO adapter, and multi-replica deployments silently drop cross-pod events without it. The chart steps aside whenever it can tell you are supplying `REDIS_URL` yourself, so no upgrade reroutes an existing instance:
476
+
* **Redis is now bundled** (`redis.enabled: true`), matching the Docker Compose stack. Redis backs pub/sub and the Socket.IO adapter, and multi-replica deployments silently drop cross-pod events without it.
477
477
478
-
| Your configuration | Bundled Redis | `REDIS_URL` |
479
-
|---|---|---|
480
-
| Default install | Deployed | Points at the bundled instance |
481
-
| `app.env.REDIS_URL` set | Not deployed | Your value |
482
-
| `externalSecrets.remoteRefs.app.REDIS_URL` mapped | Not deployed | Synced by ESO — detected automatically |
483
-
| `redis.provideUrl: false` | Not deployed | Whatever your pre-created Secret contains |
484
-
| `redis.enabled: false` | Not deployed | Unset unless you provide it |
478
+
**An existing `REDIS_URL` always wins, wherever it comes from — no action needed on upgrade.** The bundled URL ships as a ConfigMap listed *before* the app Secret in `envFrom`. Kubernetes resolves duplicate keys by letting the last source win, so a `REDIS_URL` in your chart-managed Secret, a pre-created `existingSecret`, or one synced by External Secrets overrides the bundled value — the chart never has to read it. The bundled Redis simply fills the gap when nothing else provides a URL.
485
479
486
-
**If you use `app.secrets.existingSecret` and that Secret already contains `REDIS_URL`, set `redis.provideUrl: false`.** The chart cannot read a pre-created Secret, so it would otherwise inject a computed `REDIS_URL` as a container `env` entry, which takes precedence over `envFrom` and would shadow your value. External Secrets needs no such flag — mapping `remoteRefs.app.REDIS_URL` is detected on its own.
480
+
Set `app.env.REDIS_URL` to skip the bundled Deployment entirely (no unused pod), or `redis.enabled: false` to opt out.
0 commit comments