Fix inconsistency between postgress password key for langfuse and postgress.

[JSchuurmans]

Fixes #141

Fix

Use the same naming convention for DATABASE_PASSWORD used in langfuse-web and langfuse-worker pods as subcharts of postgress uses.

Before

The subchart of postgress modifies the secret key, by pre-pending the user name to the key. By default postgress-.
This results in a mismatch with the environment variables used in the langfuse-web and langfuse-worker pods.

After

Environment variable DATABASE_PASSWORD now also prepends db username: <username>-<userPasswordKey>.

---

Important

Fixes DATABASE_PASSWORD naming inconsistency by prepending db username to key in langfuse-web and langfuse-worker pods.

• Behavior:
  • Fixes inconsistency in DATABASE_PASSWORD environment variable naming in langfuse-web and langfuse-worker pods.
  • Environment variable key now prepends db username: <username>-<userPasswordKey>.
• Templates:
  • Updated langfuse.getEnvVar in _helpers.tpl to reflect new key format.

^{This description was created by for d424c4e. You can customize this summary. It will automatically update as commits are pushed.}

[CLAassistant]

All committers have signed the CLA.

[Steffen911]

@JSchuurmans Thank you for the contribution here! Could you sign the CLA?

[Steffen911]

@JSchuurmans And are you sure that this is backwards compatible to existing installations? How would that behavior change for someone who already has the chart installed?

[JSchuurmans]

@Steffen911 good question. I am curious how someone was able to install the Langfuse server with this Helm chart and the default settings.
I needed to patch a few things in order to make it work:

Using the following settings for the postgress sub chart:

      postgresql:
        auth:
          existingSecret: langfuse-postgresql
          secretKeys:
            userPasswordKey: password

The subchart of postgres modifies the secret key, by pre-pending the user name to the key. By default the username is postgres so it prepends with postgres-.

If I use a secret with key password, then the postgres pod fails because it expects secret key: <username>-<key>.
If I use a secret with key postgres-password (postgres is default username), then the langfuse-web and langfuse-worker pods fail to authenticate to postgres. Because the langfuse-web and langfuse-worker pods only use the userPasswordKey.

I used two patches for the langfuse-web and langfuse-worker pods, e.g.:

spec:
  template:
    spec:
      containers:
        - name: langfuse-worker
          env:
            - name: DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  key: postgres-password
                  name: langfuse-postgresql

I think the PR is a more sustainable approach than this patch, because it aligns langfuse with its usage of the postgres subchart.

I hope this make the fix and its implications more clear.

[JSchuurmans]

Hi @Steffen911, did my response answer your question and does the proposed solution pass your tests?

[Steffen911]

@JSchuurmans I attempted to run this locally again and fail to reproduce the problem you report. I'm installing the latest Langfuse chart using the minimal-installation example, i.e. with the following values.yaml overwrite:

# This values.yaml file demonstrates how to use the basic chart with a single, pre-created secret.
# Secrets must be set manually or via External Secrets Operator like https://external-secrets.io/latest or any other secret management tool.
langfuse:
  encryptionKey:
    secretKeyRef:
      name: langfuse
      key: encryption-key

  salt:
    secretKeyRef:
      name: langfuse
      key: salt

  nextauth:
    secret:
      secretKeyRef:
        name: langfuse
        key: nextauth-secret

postgresql:
  auth:
    username: langfuse-test
    existingSecret: langfuse
    secretKeys:
      adminPasswordKey: postgresql-password
      userPasswordKey: postgresql-password

clickhouse:
  auth:
    existingSecret: langfuse
    existingSecretKey: clickhouse-password

redis:
  auth:
    existingSecret: langfuse
    existingSecretPasswordKey: redis-password

s3:
  auth:
    existingSecret: langfuse
    rootUserSecretKey: s3-user
    rootPasswordSecretKey: s3-password

If I leave the postgresql.auth.username blank (i.e. let it default to postgres) I get a successful installation in both scenarios and the database migrations within the web container pass.

Can you share screenshots, error logs or yaml files from the containers that represent the unexpected state from your end and perhaps any errors you observe? It would also be helpful if you can share which versions of the sub-charts you're using. As it stands, I cannot reproduce this problem.

[JSchuurmans]

@Steffen911 Thank you for referring to the minimal installation example. I can highly recommend that people read it.

I noticed that I only set the userPasswordKey, while the values.yaml example also provides adminPasswordKey.

It is still unclear how "not providing the adminPasswordKey" can lead to a valid deployment, but only if patches or a fix like this PR are applied. I can imagine it is undesired to support this workflow, but I will leave that up to you @Steffen911.

Again, thank you!