-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes to chart with postgresql.enabled = false
and external postgres break deployment
#358
Comments
Thanks for reaching out @ahgraber 👋🏼 We'll take a look at this and see which way works best to make this more flexible. |
On a similar note, our deployment also broke due from #341 to the environment variable PREFECT_API_DATABASE_CONNECTION_URL now being always set in the deployment whether postgresql is enabled or not. Previously we disabled postgres and set it manually to a sqlite connection string. As a workaround we now had to create a secret with the sqlite connection string and reference it in |
Thanks for the feedback. The thinking was that variable needs to be set whether or not the PostgreSQL chart is in use because Prefect needs to know how to reach the database no matter what. We'll keep refactoring this to be more flexible as part of this issue and #345. Welcoming any specific suggestions and/or feedback on PRs as they come 👍🏼 |
Just ran into the same issue with cloudnativePG. In my opinion, the best way to handle this, is to build the URL at runtime and expect username, password, database, host and port while leaving the option to provide a fixed URL (if one must). This exposes a clear API while being robust to internal changes (eg change to a different driver) and is consistent with the API that psql has. Ill give this a try on a fork and file a PR if i get anywhere. |
Ensures that the PostgreSQL Secret is created, even if `postgresql.enabled=false`. This ensures that we support a use case where folks want to use an external instance of PostgreSQL, but still want the Secret to automatically be generated with the proper connection string. With a recent change, we would skip creation of this secret if PostgreSQL was disabled which forced users to create a Secret themselves. This change now allows them to continue providing the `auth` values and letting the chart build the Secret with the correct connection string. Closes #358
This change is released as part of https://github.com/PrefectHQ/prefect-helm/releases/tag/2024.8.13184720. Please reach out with any further feedback! |
Works great for me, TYVM!! |
Changes from #341 are breaking my deployment.
Context: I use movetokube/postgres-operator: Postgres operator for Kubernetes to dynamically provision postgres as part of my gitops deployment process. This operator creates unique auth info in a secret that does not match the expected format of the prefect helm chart.
Prior to that change, I set:
And the helpers picked up the values I was injecting in from the operator's secret at the valid targetPaths.
After #341, this approach does not work because the helm chart expects that there will be a secret named
prefect-server-postgresql-connection
and does not create the secret as it used to based on the injected values.I'd really appreciate it if the chart supported the use of external postgres while providing details in
postgres.auth
andpostgres.externalHostname
or supported passing the fullpostgresql+asyncpg://{username}:{password}@{hostname}/{database}
connection url as an option.The requirement to use the
prefect-server-postgresql-connection
secret that does not work with my gitops deployments! Thank you!The text was updated successfully, but these errors were encountered: