You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The postgresql instance is created, a secret is generated and the deployment points to that secret. Perfect!
However, at a later stage, when I try to do a helm diff upgrade pact-broker pact-broker/pact-broker --version 1.1.0 (for example), one gets an error at first:
PASSWORDS ERROR: You must provide your current passwords when upgrading the release.
Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims.
Further information can be obtained at https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues/#credential-errors-while-upgrading-chart-releases
Makes sense: the password has to be provided.
However, if I do provide the password (either via values file or via --set postgresql.auth.password=$(kubectl get secret --namespace "observability" pact-broker-postgresql -o jsonpath="{.data.user-password}" | base64 -d)), the diff will be something like:
meaning that my deployment will be overriden and it will stop looking for the secret and go directly for a plaintext password, which is clearly unintended.
To my understanding this is related to how this part is being run.
That is to say, if one needs to provide the password and then the template will use that value if provided, it seems impossible to maintain the variable set to a secret value when upgrading versions.
Seems like this is a bug?
The text was updated successfully, but these errors were encountered:
Well, slight update: if one uses the global.postgresql.auth.password instead it seems like the overriding does not happen and the upgrade will happily go through.
I'm not entirely sure this has other side effects, but did not seem to be the case for the simple case at the very least.
I'll leave the issue open so that all facts can be brought to light. Maybe this was intentional? I'm not fully sure. I'd be happy to help w/ reproducing the issue or even a fix if this is considered to be a bug.
Hi @conilas, the postgres functionality can be quite tricky as there are bits of logic we do in the chart (which you've linked) but there's also some quirks to the way the underlying Postgres sub-chart that we're using. Have you had a look into bitnami/charts#16417 ? As when you upgrade, it tries to generate the password, instead try to get the password and create your own secret with it in, and reference it in the Chart?
Hello there!
So it seems that I've run into a conundrum.
When first installing the helm chart, i.e by simply:
The postgresql instance is created, a secret is generated and the deployment points to that secret. Perfect!
However, at a later stage, when I try to do a
helm diff upgrade pact-broker pact-broker/pact-broker --version 1.1.0
(for example), one gets an error at first:Makes sense: the password has to be provided.
However, if I do provide the password (either via values file or via
--set postgresql.auth.password=$(kubectl get secret --namespace "observability" pact-broker-postgresql -o jsonpath="{.data.user-password}" | base64 -d)
), the diff will be something like:meaning that my deployment will be overriden and it will stop looking for the secret and go directly for a plaintext password, which is clearly unintended.
To my understanding this is related to how this part is being run.
That is to say, if one needs to provide the password and then the template will use that value if provided, it seems impossible to maintain the variable set to a secret value when upgrading versions.
Seems like this is a bug?
The text was updated successfully, but these errors were encountered: