Let Deployment use secretRef even when embedded PostgreSQL is enabled

[Donnie]

retool-helm/charts/retool/templates/deployment_backend.yaml

Line 184 in c7d8d30

{{- if .Values.postgresql.enabled }}

It would be great if we could use the config.postgresql.passwordSecretName secretref even when we use the embedded postgres.

The way it is now, any small change to the helm file triggers regeneration of the random password, and everything breaks.

Or one has to hardcode the secret into the helm values file.

[jjlgao]

Hi Donnie,

Apologies for the late response here. I'm not sure I fully understand, are you looking for the config.postgresql.passwordSecretName param to override the name part of the config if it's provided? Is this because the template command forces regeneration whenever it has to be rerun, even if the actual name of the secret doesn't ultimately change? Apologies, I haven't seen this happen, so I'm not familiar with the behavior you're mentioning.

          {{- if  .Values.postgresql.enabled }}
                name: {{ template "retool.postgresql.fullname" . }}

Can take care of the change once I make sure I understand what the ask is.

Thanks,
Jason

[Donnie]

Hi Jason,

Yes, exactly. When using the embedded PostgreSQL, any change to the helm file causes the template command to regenerate the PostgreSQL password, even if the changes are unrelated to PostgreSQL. This breaks the existing database connection.

What I'd like is to be able to specify a fixed secret name using config.postgresql.passwordSecretName even when using the embedded PostgreSQL. This way we can maintain a stable password across helm updates.

Currently, the template only allows using config.postgresql.passwordSecretName when postgresql.enabled is false. I'd like to be able to override the secret name regardless of whether we're using embedded PostgreSQL or not.

Does that help clarify? Let me know if you need any additional details.

Here's a suggested change to fix this issue. We can modify the password secret reference section to check for config.postgresql.passwordSecretName first, regardless of whether PostgreSQL is enabled:

- name: POSTGRES_PASSWORD
  valueFrom:
    secretKeyRef:
      {{- if .Values.config.postgresql.passwordSecretName }}
      name: {{ .Values.config.postgresql.passwordSecretName }}
      key: {{ .Values.config.postgresql.passwordSecretKey | default "postgresql-password" }}
      {{- else if .Values.postgresql.enabled }}
      name: {{ template "retool.postgresql.fullname" . }}
      {{- if eq .Values.postgresql.auth.username "postgres" }}
      key: postgres-password
      {{- else }}
      key: password
      {{- end }}
      {{- else }}
      name: {{ template "retool.fullname" . }}
      key: postgresql-password
      {{- end }}

This change allows users to:

1. Override the secret name using config.postgresql.passwordSecretName regardless of PostgreSQL configuration
2. Fall back to the embedded PostgreSQL secret if no override is provided
3. Use the default template-generated secret as a last resort

This maintains backwards compatibility while solving the password regeneration issue for embedded PostgreSQL deployments.

Let me know what you think.

Thanks,
Donnie

[jjlgao]

That makes sense to me, thank you! If you are able to take the time to make a PR, happy to review it, otherwise will try to get to this eventually.