[stable/postgresql] Error upgrading: can't evaluate field pullSecrets in type interface {}

[luisdavim]

Version of Helm and Kubernetes:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-28T15:18:13Z", GoVersion:"go1.11", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

$ helm version
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Which chart:
stable/postgresql version 2.1.0

What happened:

I have a chart that requires the PostgreSQL chart and when running helm upgrade on my chart I get the following error from the postgresql chart:

Error: UPGRADE FAILED: render error in "thingworx/charts/postgresql/templates/statefulset.yaml": template: thingworx/charts/postgresql/templates/statefulset.yaml:35:20: executing "thingworx/charts/postgresql/templates/statefulset.yaml" at <.Values.image.pullSe...>: can't evaluate field pullSecrets in type interface {}

Also, I'm not making any changes that would affect the posrgresql chart, all that I'm doing is modifying a docker image tag for a deployment from my own chart.

What you expected to happen:

The upgrade to be done without errors.

How to reproduce it (as minimally and precisely as possible):

I think that if you create any simple helm chart, make it require the postgres chart, deploy it and then try to upgrade it you should be able to reproduce the issue.

[luisdavim]

In my case, I don't have .Values.image.pullSecrets or .Values.postgresql.image.pullSecrets defined anywhere and that is probably causing {{- if .Values.image.pullSecrets }} to fail. should I specifically set it to null or false?

[luisdavim]

I was able to workaround this issue by adding --set postgresql.image.pullSecrets=null to my helm upgrade command but I think this should be fixed in the chart.

[LeandroPT]

Someone is changing this chart drastically.

In fact V2.0 is bitnami version which is somewhat differente with previous one, starting with the image, and not placing the metrics as sidecar.

#8691
8bd8912#diff-fb61f7f926e5bfb00f3b15a715d90302

so @carrodher is this chart going to bitnami version??

[carrodher]

Yes, on this issue #7956 and Chart Office Hour meeting, we discussed the differences between the previous stable chart and the Bitnami one. After taking a look at the status of the previous one and the lack of maintenance and owners, the community decided to start working on migration towards a new model. After some weeks working on #8004, today the new version was merged.

As it is an important change, the major version was bumped, so currently, the chart is using the 2.X.X branch. If you are using this chart as a dependency with latest tag, X.X.X, 2.X.X or something like that, it is normal that appears different issues.

At this moment it is documented how to upgrade the chart itself https://github.com/helm/charts/blob/master/stable/postgresql/README.md#upgrade

For example, stable/odoo chart is using PostgreSQL as deps so if we want to use the latest PostgreSQL version we need to do some changes b822b65 in order to adapt it to the new chart (that it the reason to increase the version in a major way even in Odoo), if we want to use the previous version as usual we can create a requirements.yaml file. This is a good practice to avoid major changes cause breaking issues, almost all stable charts follow this approach, the following example is from stable/sonarqube chart.

dependencies:
  - name: postgresql
    version: 0.8.3
    repository: https://kubernetes-charts.storage.googleapis.com/
    condition: postgresql.enabled
  - name: mysql
    version: 0.6.0
    repository: https://kubernetes-charts.storage.googleapis.com/
    condition: mysql.enabled

[luisdavim]

@carrodher I don't think the problem that I've reported is because of the changes from the older version. I did had to rename some values from postgres* to postgresql* but that's fine. What I'm reporting is that I don't use image pull secrets and I had to specially set postgresql.image.pullSecrets to null to make it work that should at least be documented.

[okandas]

I am running this command,

 helm install --name timescaledb \
--set service.type=NodePort,service.nodePort=30543,image=timescale/timescaledb,imageTag=latest-pg10,postgresPassword=rueray,image.pullSecrets=null  \
stable/postgresql

and then getting this error

panic: interface conversion: interface {} is string, not map[string]interface {}

But before the chart update 3 days ago everything was working fine

[carrodher]

Hi @luisdavim, after some investigations I found that the previous chart was using:

## postgres image repository
image: "postgres"
## postgres image version
## ref: https://hub.docker.com/r/library/postgres/tags/
##
imageTag: "9.6.2"

## Specify a imagePullPolicy
## 'Always' if imageTag is 'latest', else set to 'IfNotPresent'
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
##
# imagePullPolicy:

## Specify imagePullSecrets
## ref: https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod
##
# imagePullSecrets: myregistrykey

while the new one:

## Bitnami PostgreSQL image version
## ref: https://hub.docker.com/r/bitnami/postgresql/tags/
##
image:
  registry: docker.io
  repository: bitnami/postgresql
  tag: 10.5.0
  ## Specify a imagePullPolicy
  ## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
  ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
  ##
  pullPolicy: Always

  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # pullSecrets:
  #   - myRegistrKeySecretName

Previously, image was a string and now image is an object, so when you run helm upgrade you are reusing the last release's values and merging in any overrides from the command line via --set and -f. This is the default option (--reuse-values), on the other hand, if --reset-values is specified, this value is ignored.

Using --reset-values when upgrading, it reset the values to the ones built into the chart.

Does it make sense to you?

[carrodher]

Hi @okandas, since there is a new major version, some options can be different, and in this case, there are.
You can take a look at the configuration section in the README to see a list of the configurable parameters of the PostgreSQL chart and their default values. Some of the values are different comparing it to the previous one.

In your case I tried doing the following changes:

- --set service.type=NodePort,service.nodePort=30543,image=timescale/timescaledb,imageTag=latest-pg10,postgresPassword=rueray,image.pullSecrets=null
+ --set service.type=NodePort,service.nodePort=30543,image.repository=timescale/timescaledb,image.tag=latest-pg10,postgresqlPassword=rueray

please note some name changes and image.pullSecrets=null removed because it is not needed.

Using above configuration, pod is created, but the status is CrashLoopBackOff, taking a look at the logs, this is the error:

initdb: could not look up effective user ID 1001: user does not exist

Postgresql image is non-root image, there are a ton of advantages related to the use of non-root containers, but also there are some disadvantages, one of them is that some utilities (eg. Git) or servers (eg. PostgreSQL) run additional checks to find the user in the /etc/passwd file. These checks will fail for non-root container images. In order to avoid this issue, you can set securityContext.enabled=false.

Tl;DR

$ helm install --name timescaledb \
--set service.type=NodePort,service.nodePort=30543,image.repository=timescale/timescaledb,image.tag=latest-pg10,postgresqlPassword=rueray,securityContext.enabled=false \
stable/postgresql

[okandas]

@carrodher thank you. your configs worked

[stale]

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.

[stale]

This issue is being automatically closed due to inactivity.