postgresql problem

[Reez]

Hi everyone,

when I am trying to deploy on openshift, this happened:

$ helm install backstage-helm janus-idp/backstage -f values-openshift.yaml

coalesce.go:220: warning: cannot overwrite table with non table for postgresql.networkPolicy.egressRules.customRules (map[])
NAME: backstage-helm
LAST DEPLOYED: Thu May 11 17:15:40 2023
NAMESPACE: xxxxxxxxxx
STATUS: deployed
REVISION: 1
TEST SUITE: None

And the result is postgresql won't start.

[Tom Coufal]

Hi @reechang , can you please provide us more details on your upstream.postgresql values?

The coalesce.go:220: warning is a render warning for bitnami/postgres chart dependency upstream, it has no impact on the deployed resources unless you use a network policy through that dependency. As you can see the status says deployed.

This is not the cause of your issues, we need to investigate further. 🙂

[Reez]

Hi @tumido , thanks for your quick reply :)

Basically, I am using the template from janus-idp

Here is my postgresql values

 postgresql:
    enabled: true
    database: backstage
    postgresqlDataDir: /var/lib/pgsql/data/userdata
    auth:
      username: postgres
      database: backstage
    image:
      registry: registry.redhat.io
      repository: rhel9/postgresql-13
      tag: 1-73
    primary:
      securityContext:
        enabled: false
      podSecurityContext:
        enabled: false
      containerSecurityContext:
        enabled: false
      persistence:
        enabled: true
        mountPath: /var/lib/pgsql/data
      extraEnvVars:
      - name: POSTGRESQL_ADMIN_PASSWORD
        valueFrom:
          secretKeyRef:
            key: postgres-password
            name: backstage-postgresql

[Tom Coufal]

Hi again!

Can you please share with me the output of the following commands run against the namespace you're deploying to?

kubectl get pods
kubectl get events
kubectl get secrets

This is just a wild guess, but can you please check if your namespace contains backstage-postgres secret? It's a secret you reference for POSTGRESQL_ADMIN_PASSWORD env variable and I think this secret is not included as a resource of the chart. It might be the case that Kubernetes is waiting to mount this secret before starting the Postgres pods and since it's unable to locate it, it fails to start for you...

[Tom Coufal]

Hi @reechang I think I'm starting to realize where the problem comes from...

According to your initial comment above, your helm release name is backstage-helm. Looking at the blog post, it is using backstage as the release name. I think that's where the confusion comes from. Your PostgreSQL is probably looking for the backstage-postgresql secret. And this secret is nonexistent since yours is named backstage-helm-postgresql. 🙂

Can you please try changing the last line of the values snippet you've shared to:

      - name: POSTGRESQL_ADMIN_PASSWORD
        valueFrom:
          secretKeyRef:
            key: postgres-password
-            name: backstage-postgresql
+            name: backstage-helm-postgresql

In the meantime, I'll work on updating the blog post to be more agnostic to the helm releases and provide better defaults in our charts 🙂

[Reez]

Hi @reechang I think I'm starting to realize where the problem comes from...

According to your initial comment above, your helm release name is backstage-helm. Looking at the blog post, it is using backstage as the release name. I think that's where the confusion comes from. Your PostgreSQL is probably looking for the backstage-postgresql secret. And this secret is nonexistent since yours is named backstage-helm-postgresql. 🙂

Can you please try changing the last line of the values snippet you've shared to:

      - name: POSTGRESQL_ADMIN_PASSWORD
        valueFrom:
          secretKeyRef:
            key: postgres-password
-            name: backstage-postgresql
+            name: backstage-helm-postgresql

In the meantime, I'll work on updating the blog post to be more agnostic to the helm releases and provide better defaults in our charts 🙂

Hi @tumido, I think your assumption is correct. I tested it on a different cluster with a different release name and it seems to work now. Thanks for your time. :)