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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
