This is an automated email from the ASF dual-hosted git repository.
github-merge-queue[bot] pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/texera.git
The following commit(s) were added to refs/heads/main by this push:
new f14cd3975e fix(k8s): add missing AUTH_JWT_SECRET to
values-development.yaml (#6610)
f14cd3975e is described below
commit f14cd3975e7446b77241990b7d573d182d61f88f
Author: ali risheh <[email protected]>
AuthorDate: Mon Jul 20 14:09:26 2026 -0700
fix(k8s): add missing AUTH_JWT_SECRET to values-development.yaml (#6610)
### What changes were proposed in this PR?
Adds the `AUTH_JWT_SECRET` environment variable to
`bin/k8s/values-development.yaml`.
The default `values.yaml` sets `AUTH_JWT_SECRET` inside `texeraEnvVars`,
but `values-development.yaml` overrides `texeraEnvVars` as a **whole
list**. Helm replaces lists rather than merging them, so a local install
with `-f values-development.yaml` silently drops `AUTH_JWT_SECRET` from
every Texera service.
The computing-unit manager reads this variable directly via
`env.get(KEY).get` when launching a Kubernetes computing unit
(`ComputingUnitManagingResource.scala`), so the missing value makes
**computing-unit creation fail hard**:
```
java.util.NoSuchElementException: None.get
POST /api/computing-unit/create HTTP/1.1" 500
```
Any local Kubernetes deployment following the development values hits
this the moment a user tries to create a computing unit. The fix adds
the variable with the **same development-only default** already used in
`values.yaml`, so all services share one consistent JWT signing secret.
### Any related issues, documentation, discussions?
None — standalone bug fix in the development values overlay. Independent
of any other in-flight `bin/k8s` work.
### How was this PR tested?
Reproduced and verified on a local minikube cluster (`helm install ...
-f values-development.yaml`):
- **Before:** creating a Kubernetes computing unit returned HTTP 500;
the computing-unit manager logged `java.util.NoSuchElementException:
None.get`. `kubectl exec` into the manager pod confirmed
`AUTH_JWT_SECRET` was unset.
- **After** (`helm upgrade` with this change): `AUTH_JWT_SECRET` is
present on the manager (and all services), the manager rolled out
cleanly, and the `None.get` error no longer occurs.
Also confirmed the added value is byte-for-byte identical to the
`AUTH_JWT_SECRET` default in `values.yaml`, so development and
production use the same variable and the dev overlay stops diverging.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 4.8)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
---
bin/k8s/values-development.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/bin/k8s/values-development.yaml b/bin/k8s/values-development.yaml
index dc7078e468..aa64d6ecbc 100644
--- a/bin/k8s/values-development.yaml
+++ b/bin/k8s/values-development.yaml
@@ -352,6 +352,12 @@ texeraEnvVars:
value: ""
- name: USER_SYS_DOMAIN
value: ""
+ - name: AUTH_JWT_SECRET
+ # Obvious non-secret placeholder for LOCAL DEVELOPMENT ONLY (64 chars =
512-bit
+ # HMAC key, well above the 256-bit HS256 minimum). All services must share
the
+ # same value, so this is a fixed shared string rather than a per-pod
random one.
+ # Production environments MUST override this with a securely generated
secret.
+ value: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
yWebsocketServer:
name: y-websocket-server