You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@texera.apache.org by "aicam (via GitHub)" <gi...@apache.org> on 2026/08/19 19:24:23 UTC
[PR] fix(k8s): make the Helm chart work under any release name [texera]
aicam opened a new pull request, #7788:
URL: https://github.com/apache/texera/pull/7788
### What changes were proposed in this PR?
The chart derives in-cluster hostnames from `.Release.Name`, but the `lakefs` and
`lakekeeper` sub-charts have to address Postgres and MinIO from **their own** values
blocks — and Helm does not template values files, so those references are hardcoded to
`texera-postgresql` / `texera-minio`:
```yaml
# bin/k8s/values.yaml
lakefs:
secrets:
databaseConnectionString: postgres://postgres:root_password@texera-postgresql:5432/...
lakefsConfig: |
blockstore:
s3:
endpoint: http://texera-minio:9000
lakekeeper:
externalDatabase:
host_read: texera-postgresql
host_write: texera-postgresql
```
Those names only exist when the Helm release happens to be named `texera`. Install under
any other release name and they dangle — LakeFS cannot reach the database or the object
store, and Lakekeeper cannot reach the database, while every other service (which goes
through `{{ .Release.Name }}-postgresql` in the templates) works fine. The failure is
confusing because the chart installs cleanly and only the storage tier misbehaves.
Rendering `helm template myrel bin/k8s` on `main` today:
| Reference | Points at | Service actually created |
|---|---|---|
| `Secret/myrel-lakefs` → `database_connection_string` | `texera-postgresql` | `myrel-postgresql` |
| `ConfigMap/myrel-lakefs` → `blockstore.endpoint` | `texera-minio:9000` | `myrel-minio` |
| `Secret/myrel-lakekeeper-config-envs` → `LAKEKEEPER__PG_HOST_R` / `_W` | `texera-postgresql` | `myrel-postgresql` |
**The fix.** Since the referencing side cannot be templated, make the referenced side a
constant: pin the two sub-charts with `fullnameOverride`, and resolve the same names in
chart templates through two new helpers so both sides always agree.
```yaml
postgresql:
fullnameOverride: texera-postgresql
minio:
fullnameOverride: texera-minio
```
```gotemplate
{{- define "texera.postgresql.fullname" -}}
{{- .Values.postgresql.fullnameOverride | default (printf "%s-postgresql" .Release.Name) -}}
{{- end -}}
```
The helpers keep the previous `<release>-<chart>` form as a fallback, so clearing the
override restores the old naming rather than breaking the chart. The 12 template
references to `{{ .Release.Name }}-postgresql` (JDBC URLs + the password `secretKeyRef`),
the two MinIO references in `_helpers.tpl`, the LiteLLM `DATABASE_URL`, and the
`ExternalName` mirrors in the computing-unit namespace all go through the helpers now.
The chart-generated S3 credentials Secret gets a fixed name for the same reason:
`values-aws.yaml` wires it into `lakefs.extraEnvVars` and carried a note telling the
reader to hand-edit both `name:` fields when the release is not called `texera`. That
note is no longer needed and has been dropped.
One consequence worth calling out for reviewers: the pinned names make the chart
release-name independent, but they also mean two Texera releases can no longer coexist in
a single namespace. That was already effectively true — `workflowComputingUnitPool.namespace`
and the `ExternalName` mirrors collide between releases regardless, and `values.yaml`
already warns about it — so this codifies an existing constraint rather than adding one.
### Any related issues, documentation, discussions?
No separate issue was filed; the problem was found while writing cluster deployment
notes for the chart. Comments in `values.yaml`, `values-aws.yaml` and `_helpers.tpl` are
updated in this PR to explain why the names are pinned, so the constraint is documented
where someone would next be tempted to un-pin it.
### How was this PR tested?
The chart has no automated render tests, so this was verified by rendering and diffing.
**1. Existing deployments are unaffected — release `texera` renders byte-identically.**
Rendered `helm template texera bin/k8s` before and after the change, for all three values
files, and diffed (filtering only Lakekeeper's `encryptionKey`, which the sub-chart
regenerates randomly on every render):
```
IDENTICAL release=texera values.yaml
IDENTICAL release=texera values-aws.yaml
IDENTICAL release=texera values-development.yaml
```
**2. The bug is fixed for other release names.** A script parses the rendered manifests,
base64-decodes Secret values (so `LAKEKEEPER__PG_HOST_*` and the LakeFS connection string
are visible), collects every reference to a `*-postgresql` / `*-minio` /
`*-s3-credentials` object, and checks each one against the set of resources the render
actually creates:
```
===== BASELINE (main) =====
DANGLING release=myrel
-> texera-minio (referenced, never created)
-> texera-postgresql (referenced, never created)
===== AFTER FIX =====
CLEAN release=texera / myrel / other-name x values.yaml, values-aws.yaml, values-development.yaml
```
All nine combinations (3 release names x 3 values files) render with no dangling
references, and `helm lint` passes.
Not covered: this is a static render check, so it verifies the names now agree; it does
not exercise a live LakeFS/Lakekeeper connection under a non-`texera` release. Given the
only change is which hostname string is emitted, and release `texera` is unchanged, an
in-cluster run seemed disproportionate — happy to add one if a reviewer prefers.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 5
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(k8s): make the Helm chart work under any release name [texera]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #7788:
URL: https://github.com/apache/texera/pull/7788#issuecomment-5347086237
<!-- backport-auto-label-report -->
### Backport auto-label report
This `fix:` PR was checked against each actively-supported release branch. `release/*` labels drive the post-merge backport, so add or remove one to change where this fix lands.
| Release branch | Analysis |
| --- | --- |
| ✅ `release/v1.2` | Change detected on this branch — label added; this fix is queued to backport here. Requested review from @xuang7. |
_[Auto-label run](https://github.com/apache/texera/actions/runs/32292842599)._
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(k8s): make the Helm chart work under any release name [texera]
Posted by "parshimers (via GitHub)" <gi...@apache.org>.
parshimers commented on PR #7788:
URL: https://github.com/apache/texera/pull/7788#issuecomment-5543565441
I think this is a really important fix. I ran into this issue myself when trying to have a staging, and stable Texera deployment within one k8s cluster.
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(k8s): make the Helm chart work under any release name [texera]
Posted by "xuang7 (via GitHub)" <gi...@apache.org>.
xuang7 commented on PR #7788:
URL: https://github.com/apache/texera/pull/7788#issuecomment-5745264537
Removing the release/v1.2 label: non-default release names never worked, so this enables a capability rather than restoring previously working behavior; the change also predates the RustFS switch and would need rework before any backport. Ships with 1.3.0.
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(k8s): make the Helm chart work under any release name [texera]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #7788:
URL: https://github.com/apache/texera/pull/7788#issuecomment-5347089301
<!-- texera-reviewer-suggestion -->
### Automated Reviewer Suggestions
Based on the `git blame` history of the changed files, we recommend the following reviewers:
- **Contributors with relevant context:** `@bobbai00`, `@mengw15`, `@tanishqgandhi1908`
You can notify them by mentioning `@bobbai00`, `@mengw15`, `@tanishqgandhi1908` in a comment.
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(k8s): make the Helm chart work under any release name [texera]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #7788:
URL: https://github.com/apache/texera/pull/7788#issuecomment-6406258321
This pull request has been automatically marked as **stale** because it has
not had any activity for 30 days. It will be closed in **7 days** if no
further activity occurs.
If this PR is still relevant, please:
- Push new commits or rebase onto the latest `main`, or
- Comment with a status update, or
- Address any open review feedback.
To exempt this PR from auto-close, a maintainer can add the `pinned` label.
Thank you for your contribution to Apache Texera (incubating)!
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org