pgAdmin4 not working with PG15 and PG16

[mzwettler2]

pgAdmin4 not working with PG15 and PG16

[tjmoore4]

Hi @mzwettler2. At this time, the PostgresCluster-Scoped pgAdmin is not compatible with PostgreSQL 15 and newer, and we are currently focusing our attention on the new Namespace-scoped pgAdmin that was included in the CPK v5.5.0 release.

Have you had an opportunity to try the new pgAdmin API? This is our brand-new, modern API for pgAdmin, which has full support for both Postgres 15 and 16.

I therefore definitely recommend checking it out if you haven't already done so. We'd certainly be curious to hear about your experience with this new implementation, and welcome any feedback.I also recommend checking the following blog for a great introduction to the new API: https://www.crunchydata.com/blog/cpk-5-5-a-new-pgadmin-experience

[mzwettler2]

@tjmoore4

Yes, we have tried the new variant and will use it out of necessity, as the old variant does not work with PG 15 and PG 16.

We only have one PG cluster per namespace, so the old variant was better for our purposes, as the defined users from spec.users were synchronized to PGAdmin. With the new variant, normal PGAdmin users must now be created and maintained manually.

Once again, any plans that the Cluster scoped pgAdmin4 version is also updated?

[andrewlecuyer]

Hi @mzwettler2!

At this time we our focusing our efforts on the new Namespace-scoped pgAdmin API. We therefore do not have any immediate plans to add Postgres 15 or 16 support to the PostgresCluster-Scoped pgAdmin solution.

This means you will need to leverage the new pgAdmin API to have full support for the latest versions of Postgres (e.g. PG 15 & 16).

As for user-sync functionality you referenced, it sounds like this is the primary benefit of the cluster-scoped solution that you would like to continue to leverage? I'll note that this functionality is something we have considered for the new API as well.

However, as you might be able to imagine, since a single pgAdmin is now able to support more than one PostgresCluster, this also means multiple cluster could have the same spec.users defined, complicating the ability to synchronize with pgAdmin. We therefore definitely welcome any thoughts or feedback you might have as to how we might be able design & implement similar functionality within the new API.

[mzwettler2]

@andrewlecuyer

As for user-sync functionality you referenced, it sounds like this is the primary benefit of the cluster-scoped solution that you would like to continue to leverage? I'll note that this functionality is something we have considered for the new API as well.

Yes. That is exactly my point.

We therefore definitely welcome any thoughts or feedback you might have as to how we might be able design & implement similar functionality within the new API.

I am afraid I don't have "the" solution. one solution could be a new key "spec.users.addToPGAdmin". another could be to always append the cluster name to the spec.users.name to get unique names in PGAdmin.

[mzwettler2]

@andrewlecuyer

I played with the namespace-scoped variant for a while.

If no spec.users are synchronized to pgAdmin, then it would at least be helpful if another "normal" pgAdmin user would be created by default in addition to the "admin" pgAdmin Administrator.

The pgAdmin secrets should always have the same name. One appropriate format could be e.g:
<<namespace>>-pgadmin-<<admin>>
<<namespace>>-pgadmin-<<user>>

(Background: We synchronize the passwords from Hashicorp Vault to the secrets. However, this does not work well if the secret names are subject for change, eg. in case of a redeployment).