pgAdmin 'ServerManager' object has no attribute 'user_info'

[nniehoff]

Describe the bug

When standing up a new HA db with pgbouncer and pgadmin enabled following the guides and logging in to pgAdmin I receive an error 'ServerManager' object has no attribute 'user_info'

To Reproduce

Steps to reproduce the behavior:

1. Create a cluster with the attached yaml (see first comment)
2. Log in to pgAdmin as db@pgo
3. Browse to the database

Expected behavior

I'm able to browse the database

Screenshots

Please tell us about your environment:

• Operating System: Ubuntu 22.04
• Where is this running ( Local, Cloud Provider) K0s Cluster
• Storage being used (NFS, Hostpath, Gluster, etc): Hosstpath
• Container Image Tag: registry.developers.crunchydata.com/crunchydata/crunchy-pgadmin4:ubi8-4.30-16
• PostgreSQL Version: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-15.3-3
• Platform (Docker, Kubernetes, OpenShift): Kubernetes
• Platform Version: 1.27
• Helm Chart Version: pgo-5.4.1

Additional context

pgAdmin is version 4.x and version 7.x is out, a little googling suggest maybe a newer image would help. I'm unable to find available tags for the registry.developers.crunchydata.com/crunchydata/crunchy-pgadmin4 but I suspect if a newer version is available this would fix my issue.

[nniehoff]

  ---
  apiVersion: "postgres-operator.crunchydata.com/v1beta1"
  kind: "PostgresCluster"
  metadata:
    name: "db"
  spec:
    postgresVersion: 15
    instances:
      - name: "db"
        replicas: 3
        dataVolumeClaimSpec:
          storageClassName: "manual"
          selector:
            matchLabels:
              postgres-operator.crunchydata.com/cluster: "db"
              postgres-operator.crunchydata.com/instance-set: "db"
          accessModes:
          - "ReadWriteOnce"
          resources:
            requests:
              storage: 1Gi
        affinity:
          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              podAffinityTerm:
                topologyKey: "kubernetes.io/hostname"
                labelSelector:
                  matchLabels:
                    postgres-operator.crunchydata.com/cluster: "db"
                    postgres-operator.crunchydata.com/instance-set: "db"
    backups:
      pgbackrest:
        repos:
        - name: "repo1"
          volume:
            volumeClaimSpec:
              accessModes:
              - "ReadWriteOnce"
              resources:
                requests:
                  storage: 1Gi
    proxy:
      pgBouncer:
        replicas: 2
        affinity:
          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              podAffinityTerm:
                topologyKey: "kubernetes.io/hostname"
                labelSelector:
                  matchLabels:
                    postgres-operator.crunchydata.com/cluster: "db"
                    postgres-operator.crunchydata.com/role: "pgbouncer"
    userInterface:
      pgAdmin:
        dataVolumeClaimSpec:
          accessModes:
            - 'ReadWriteOnce'
          resources:
            requests:
              storage: 1Gi

[AlessandroFazio]

Same issue, I've read that a new image can help solve the problem. Setting psql version to 14 seems to crash the database container. Solutions for now is to deploy pgAdmin with newer image version as a standalone resource. Hope someone could do something for at least chaning the image to a newer version.

[AlexProgrammerDE]

According to StackOverFlow this is a issue that occurs with old versions of pgAdmin4: https://stackoverflow.com/a/74224756 I would suggest the maintainers update pgAdmin4 to a newer version, right now the version is 4.30 and the latest version is 7.7. The version of pgAdmin4 is set in the Makefile here: https://github.com/CrunchyData/crunchy-containers/blob/9339040f8ff166a6d6d218e8f73b6f062be15af0/Makefile#L16

[kuznero]

Same error when running Postgres 16

[benjaminjb]

I'm sorry to hear you've run into this and we are aware of this problem.

I'm happy to announce we have just released a new, more up-to-date pgAdmin4 image that should no longer exhibit this bug. This new image is only usable with our new namespace-scoped pgAdmin4 API. Please check out our docs for an in-depth walkthrough of this new CRD and workflow.

This new pgAdmin image (and new implementation) should fix this problem, but if it doesn't or if there're any questions about this, please reach out on our Discord.