bikash-barnwal opened a new pull request, #43214:
URL: https://github.com/apache/superset/pull/43214
### SUMMARY
The chart advertises `extraEnv`, `extraEnvRaw` and `envFromSecrets` as
chart-wide environment injection, and applies them to every main container —
`deployment.yaml:106-127`, and the same block in `-worker`, `-beat`, `-flower`,
`-ws`, `-mcp`, plus the init-db Job container in `init-job.yaml:78-94`.
Its own init containers never receive them. They are data in `values.yaml`
(`supersetNode.initContainers:429-436`, worker `:557`, beat `:680`, flower
`:799`, ws `:917`, mcp `:1060`, init job `:1168`), each hardcoding `envFrom:
[secretRef: envFromSecret]` only, rendered with a plain `tpl (toYaml ...)`.
Those containers wait on the metadata DB and Redis using `DB_HOST` /
`DB_PORT` / `REDIS_HOST` / `REDIS_PORT`. When those values come from a
pre-existing Secret via `envFromSecrets`, or from `secretKeyRef` entries in
`extraEnvRaw`, the init containers keep the chart's stub defaults and loop
until timeout — while the application container would have connected fine. That
is the concrete half of #42876: *"`extraEnvRaw` and `extraSecretEnv` don't get
passed through to the init container, so startup is still blocked."*
A new `superset.initContainers` helper deep-copies each container and
**appends** `extraEnv`/`extraEnvRaw` to `env` and `envFromSecrets` to
`envFrom`, so anything a container already declares is preserved and the
chart-managed secret stays first. `extraInitContainers` is deliberately
untouched — it is user-owned, mirroring `extraContainers`.
**Scope.** This does *not* add first-class `database.existingSecret` /
`passwordKey` plumbing, which is the other half of that issue. Sourcing
`database.*` from a pre-existing Secret is a new capability (the shape PR
#42753 added for admin credentials) and a maintainer call, so the issue should
stay open for it. What is fixed here is an internal inconsistency in the chart,
not a missing feature.
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Not applicable — Helm templates.
### TESTING INSTRUCTIONS
```bash
helm lint helm/superset
helm unittest helm/superset
helm template rel helm/superset # default
values
helm template rel helm/superset -f your-existing-secret-values.yaml
```
Verified with helm 3.19.0 and helm-unittest v1.1.1 (the version pinned in
`.github/workflows/superset-helm-lint-test.yml:74`):
- `helm lint` — 0 failed.
- `helm unittest` — 11 suites, **115/115 pass**, including 5 new cases in
`tests/init_containers_test.yaml`: defaults unchanged, `envFromSecrets`
(including a templated name), `extraEnv` + `extraEnvRaw`, a custom init
container keeping its own `env`/`envFrom`, and the init-db Job.
- `helm template` with **default values**, before vs after: identical apart
from the bitnami subchart's randomly generated `postgres-password` — i.e.
backward compatible.
- `helm template` with an existing-secret values file, before vs after: the
only diff is the intended `env:` plus two `secretRef:` entries on all 7 init
containers, with `{{ .Release.Name }}-extra-creds` correctly rendering to
`rel-extra-creds`.
Chart version bumped 0.22.6 → 0.22.7 with the README badge updated to match,
following the convention in `95e5e25e1a`. No `values.yaml` change, so helm-docs
has nothing else to regenerate.
Not verified: nothing was deployed to a live cluster, so "the init container
now reaches an external CNPG/RDS instance" is inferred from the rendered
manifests rather than observed.
### ADDITIONAL INFORMATION
- [x] Has associated issue: Addresses #42876
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
