Is this a request for help?:
Yes
Version of Helm and Kubernetes:
helm 2.10.0
kubernetes: 1.10
Which chart:
stable/postgresql
What happened:
If I install the chart with
helm install --name my-release \
--set postgresUser=my-user,postgresPassword=secretpassword,postgresDatabase=my-database \
stable/postgresql
I can log in with
kubectl run --namespace serfsage my-release-postgresql-client --restart=Never --rm --tty -i --image postgres --env "PGPASSWORD=secretpassword" --command -- psql -U postgres -h my-release-postgresql my-database
However, whenever I try to install it as a subchart, I can't change the password. I try the command
helm upgrade --recreate-pods --install ${RELEASE} ./deploy/chart --namespace ${RELEASE} \
--set pg.pw=mypass \
--set postgresql.postgresUser="postgres" \
--set postgresql.postgresDatabase=staging \
--set persistence.enabled=true \
--set persistence.existingClaim="postgres-data"
But then when I try to connect with
kubectl run --namespace serfsage my-release-postgresql-client --restart=Never --rm --tty -i --image postgres --env "PGPASSWORD=secretpassword" --command -- psql -U postgres -h myproject-postgresql staging
I get the error that it could not authenticate my password.
What you expected to happen:
It to accept my password in both cases
How to reproduce it (as minimally and precisely as possible):
run the previous listed commands
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
This issue is being automatically closed due to inactivity.
Has this been resolved? I'm experiencing the same issue
I'm facing this issue with stable version 2.4.0. Environment variable 'POSTGRESQL_PASSWORD' in the container is set to what I had passed from values.yaml file, however I cannot login to postgres cli using this password.
Same configuration, works as expected when used as a single chart
@zwhitchcox Did you find any workaround for this issue.
+1
I seem to be running into this issue as well. Any suggestions?
Same issue on 2.7.8. and tried it on 1.0.0; same problem. Unfortunately wasted two hours on this issue. It did not occur to me that it would be because of a subchart because the outputs from the templates looked fine. Anyone find anything?
So I'm just having trouble logging in when installing it directly from stable as well. Has anyone else had the same issue?
UPDATE:
My issue was related to some stale data in a persistent volume. Removing it from the sub chart fixed the issue for me.
I think I'm having this this issue. Did anyone resolve it?
following @k 's advice, deleting the persistentVolumeclaim solved it for me
I am also having the same issue. has anyone solved it
What an insanely dumb issue to waste time on! Deleting the PV is obvious when you think about it and if you are experienced with helm. If you are not, you may waste a lot of time... like us :(
kubectl exec -it ses-db-postgresql-0 bash
sed -i 's/md5/trust' /opt/bitnami/postgresql/data/pg_hba.conf
pkill postgres
ps -ef | grep postgres to ensure all the postgresql processes are killed.
kubectl port-forward --namespace default svc/xxxx-postgresql 5432:5432 &
psql -h 127.0.0.1 -U postgres
I'm running into the same issue. Perhaps it's because the values are commented out here?
https://github.com/helm/charts/blob/master/stable/postgresql/values.yaml#L80
I had this issue after deleting a helm release then re-deploying with the same name and a new password.
To fix the issue, delete the release and the lingering pvc and re-deploy.
@fertiland disabling password authentication does not seem like a proper solution to this issue. (pg_hba.conf docs)
We can reset the password for PostgreSQL, documentation of how to do this is already provided by bitnami.
I have applied this & it's working perfectly fine.
https://docs.bitnami.com/aws/infrastructure/postgresql/administration/change-reset-password/
Most helpful comment
following @k 's advice, deleting the persistentVolumeclaim solved it for me