Do I need to set

postgresqlSecretName

in my User Deployment when I deploy the infrastructure (daemon , webserver) separately?

Based on the documentation, when deploying Dagster with Kubernetes and you want to use an external PostgreSQL database, you should configure the

postgresql

section of the

values.yaml

file. If you are managing your PostgreSQL credentials as a Kubernetes Secret outside of the Dagster Helm chart, you should disable the generation of this Secret within the chart by setting

generatePostgresqlPasswordSecret

to

false

. Additionally, you should set

.Values.global.postgresqlSecretName

to the name of the externally managed Secret. Therefore, if you are deploying your infrastructure components like the daemon and webserver separately and wish to use an external PostgreSQL database with credentials stored in a Kubernetes Secret, you should indeed set the

postgresqlSecretName

in your deployment configuration to point to the name of that Secret. This allows the separate components of your Dagster deployment to access the PostgreSQL database using the credentials defined in the externally managed Secret.

@Scout setting

generatePostgresqlPasswordSecret

to

false

is described for the "infrastructure" deployment that deploys the daemon and webserver but this does not seem to work for the User Deployment. I have them deployed in different namespaces so I cannot access the secret from my User Deployment. How can I tell the user deployment to stop searching for the secret?

In the case where you have the infrastructure (daemon, webserver) and User Deployments in different namespaces, and you want to use an external PostgreSQL database with credentials stored in a Kubernetes Secret that is not accessible across namespaces, you would need to manage the PostgreSQL credentials within the User Deployment's namespace. The documentation indicates that you can disable the generation of the PostgreSQL Secret within the Helm chart by setting

generatePostgresqlPasswordSecret

to

false

. However, if this setting is not working as expected for the User Deployment, it might be due to the Helm chart's design or a limitation in how the chart handles secrets for User Deployments specifically. If the Helm chart does not provide a direct way to disable the secret lookup for the User Deployment, you may need to take a different approach. One potential solution is to create a duplicate of the PostgreSQL Secret in the same namespace as the User Deployment. This way, the User Deployment can access the necessary credentials without attempting to access a Secret from another namespace. Here's a general approach you could take: 1. Create a duplicate of the PostgreSQL Secret in the namespace of the User Deployment with the same key-value pairs as the original Secret. 2. Ensure that the User Deployment's Helm chart configuration references the name of the duplicated Secret correctly. If the Helm chart for the User Deployment does not provide a way to specify the secret name or to disable the secret lookup, you might need to customize the Helm chart or seek a feature update from the maintainers of the Dagster Helm chart to support this use case. For further assistance, it would be beneficial to consult the specific Helm chart documentation for User Deployments or reach out to the Dagster community, such as through GitHub issues or discussions, to see if there are any known workarounds or upcoming features that would address this scenario.