-
Notifications
You must be signed in to change notification settings - Fork 16.8k
[stable/postgresql] Admin password not being set #10918
Comments
Hi @nrmitchi I was unable to reproduce the issue. See the details:
Did you have PVCs from previous deployments? |
Are you using the latest version of the chart?
|
The chart is version I considered left over PVs, and actually went ahead and manually deleted the PV/PVCs before trying again (I still ran into the issue). I'll do a bit more digging on my end and follow up; it's possible something weird is happening with PVs in my setup. |
Hi @nreisbeck Could the master pod be restarted before it finished the initialisation of the container (because of failing readiness/liveness probes)? |
You're right.. Sorry! |
I am running into the same issue - password is not set. Tried deleting ( The command I use:
Logs:
|
It seems you're not using Bitnami PostgreSQL image, are you? Please note that this chart is designed to work with this Docker image that has a series of initialisation scripts that sets PostgreSQL based on the env. variables used on the chart. Could you share what values are you using |
Make sure you don't have any existing
Any existing claims will be automatically reattached leaving you with the postgresqlPassword from a previously installed helm release. |
@mbalaa-spring, @nrmitchi I am not sure if it's related to timescale image or this chart, so I opened an issue with values I used there : timescale/timescaledb-docker#50 |
That image (TimescaleDB) is not maintained by Bitnami nor based on any Bitnami image. Do you face the same issues when using the |
I don't like bringing this up again, but I have raised concerns in the past about the Bitnami "ownership" of this community chart, in that it broke compatibility with community maintained charts. In my opinion, if this chart does not work with images based off of the main |
As far as I understand it is based on bitnami: |
This other Dockerfile doesn't use Bitnami as base: https://github.com/timescale/timescaledb-docker/blob/master/Dockerfile I didn't know they had an alternative image based on Bitnami's one. Are you using that image?
This topic has been extendedly discussed in the past. There were strong reasons for this move (see #8004) and the image has been adapted to support all the features existing in the image maintained by Docker Inc plus others that are only supported on Bitnami's one. IMHO we're moving to a distributed repositories model where everyone can create its own chart repository and include its own charts based on the Bitnami, Docker or any other's company images (even your own images). |
Maybe this is the issue: We are setting the statefulset env var as
https://github.com/bitnami/bitnami-docker-postgresql#setting-the-root-password-on-first-run |
I just spent a few hours chasing this too. They have release candidates for updated bitnami images that use the same environment variables as the main postgres image. No idea why #10757 was merged before the binami releases... Anyway using one of the rc tags worked for me:
More image options here. |
As @hardbyte mentioned, the Bitnami image supports both formats on env. variables as you can check in the link below: https://github.com/bitnami/bitnami-docker-postgresql#environment-variables-aliases You should be able to use bot |
@juan131 I'm not quite sure what you're saying, and just want to confirm: Was this issue corrected by a fix in the underlying bitnami docker image? If so, have the updates to the underlying image been released yet? As well, does that imply that any images based off of the previous Looking at the changes in #10757, this seems to be the second time that these parameters names have been changed in a backwards incompatible fashion (IIRC the first was when Bitnami first took "ownership" of this chart). Is there a reason that a safe update (ie, continuing to use the existing env names, while duplicating with the new name during a transition period) was not used? Is there any way that we can ensure that backwards incompatible changes are not arbitrarily introduced again in the future? |
The issue with the env. variables format "POSTGRESQL vs POSTGRES" was fixed and released. It doesn't mean it addresses your specific issue. I think the issue in your case is the master pod being restarted before it finishes the initialisation of the container Could you please share the logs of the pod during the first initialisation?
No, it implies that images based on old
AFAIK the changes included in #10757 did not introduce backwards incompatibilities. You should be able to upgrade the chart without any issue since both formats for env. variables are supported.
We do not introduce backwards incompatibilities unless there's a strong reason to do so. Of course we are humans and we make mistakes and it's impossible to guarantee that sth like that isn't happening anymore. |
I have the same issue with stable/postgresql:11.2.0 image - from what I understand from the thread it should work on it - however it does not. |
With image docker.io/bitnami/postgresql:10.7.0 helm delete --purge and deleting the PVC manually o,0 solve the problem. We might need some verification mechanism to avoid this issue? |
@123BLiN it seems you're using an old version of the MongoDB chart. Please note the latest version is 5.10.0. Can you reproduce the issue using the latest version too?
@zakkg3 were you unable to set the admin password after doing "helm upgrade"? |
@juan131 I'm trying postgres, not mongo. Btw if it matters we run it multiple times on the very fresh clusters from Terraform. Could it be that needed environment variables are not in all latests bitnami postgres images? |
Sorry @123BLiN ! My fault.. You're right but it's also an old version, isn't it? Latest PostgreSQL version is |
@juan131 the problem is the PVC have a stored passwd there. so when you upgrade a chart with postgresql as a requierement, if something changed with posgresql, helm will recreate the pod, and the password... but postgresql will find the PVC with config and the old password there. so the passwd in the secret, the one iam reading to inject in my config to connect to postgresql, is a newone different form the one in the PVC. |
We discussed this in the past an I suggested using "hooks" to avoid recreating a new secret, see #10400 It was rejected since it was considered a too complex solution. The only way to do the upgrade with the current approach is to ensure you're setting the same password when upgrading (via values.yaml or |
@zakkg3 I dont think this is related to the original issue (postgres not setting a password at all), but the problem you are seeing is a thing in a ton of different charts. To deal with it I've always specified a password manually, in all charts that require it. |
I totally agree with @nrmitchi ! It's a good practice to specify the password every-time you run |
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. |
Is this a request for help?:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT
Version of Helm and Kubernetes:
Helm:
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Kubernetes:
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T19:44:10Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
postgresql
What happened:
Installing the helm chart is not setting the admin password for the postgres user, thus only allowing connections from 127.0.0.1.
What you expected to happen:
The set password would be set, and allow connections
How to reproduce it (as minimally and precisely as possible):
helm install --set postgresqlPassword=<password> stable/postgresql
Anything else we need to know:
Setting the password in postgres after the fact makes it work, ie,
ALTER USER postgres WITH PASSWORD '<password>';
The text was updated successfully, but these errors were encountered: