Restore pgAdmin support (PGAdmin CRD is inherited but non-functional)

[yoav-katz]

Proposal

Percona's operator is forked from Crunchy Data's PGO, which ships a working PGAdmin controller. Percona still carries the inherited CRD shape, but there's no reconciler behind it - creating a PGAdmin CR is a no-op.

Before asking for it back, I'd like to understand the reasoning:

1. was dropping the pgAdmin controller during the fork intentional or simply code that didn't get ported over?
2. If it was a deliberate call, what drove it?

Use-Case

1. Teams using local PGAdmin and want to move to centrelized one
2. quick diagnostic access for on-call engineers who don't want to kubectl exec into a pod or open a psql tunnel just to run a query during an incident.
3. Teams migrating from Crunchy PGO who hit this gap during migration and have to bolt on their own pgAdmin deployment/Ingress by hand, per cluster, with no operator-managed lifecycle

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

The CRD scaffolding already exists in the codebase
so this is closer to "re-enable a controller" than "design new API surface"
unless we want to redisgn it and then I will be happy to help do so 😄

[egegunes]

Hi @yoav-katz,

I think the primary reason to dropping it was simply pgAdmin is not something we have in the Percona Distribution for PostgreSQL. And we haven't got any requests for it until very recently. With Crunchy going EOL and migrations happening, people started to ask about pgAdmin. We'll consider supporting it.

[yoav-katz]

if that helps anyhow, as always, I will be happy to contribute 😄

[egegunes]

@yoav-katz pgAdmin requires coordination between multiple teams in here, I think it'd be better if it's implemented by us.

[hors]

JIRA task is https://perconadev.atlassian.net/browse/K8SPG-1110