fix(pg): map DatabaseCluster proxy.config to PerconaPgCluster pgBouncer.config

[pvstekunov]

Description

DatabaseCluster.spec.proxy.config was not being propagated to PerconaPgCluster.spec.proxy.pgBouncer.config, so custom pgBouncer settings (e.g. default_pool_size, max_client_conn, client_tls_sslmode) were lost during reconciliation.

Changes

• pgbouncer_config.go: Add ParsePGBouncerConfig to parse spec.proxy.config YAML into PGBouncerConfiguration (global, databases, users).
• applier.go: In Proxy(), set pg.Spec.Proxy.PGBouncer.Config when database.Spec.Proxy.Config is non-empty.
• pgbouncer_config_test.go: Unit tests for the parser (empty, whitespace, global section, numeric values, invalid YAML).

Example

spec:
  proxy:
    type: pgbouncer
    config: |
      global:
        client_tls_sslmode: allow
        default_pool_size: "150"
        max_client_conn: "300"

This config is now correctly applied to the underlying PerconaPgCluster.

Testing

• go test ./internal/controller/everest/providers/pg/... — all pass
• go build ./... — succeeds

Fixes openeverest/openeverest#1823

[it-percona-cla]

All committers have signed the CLA.

[chilagrow]

Thanks for the contribution @pvstekunov 🤗

While the suggested change in openeverest-operator is sufficient for updating DatabaseCluster CR directly, changes then made on .spec.proxy by OpenEverest UI reverts and removes .spec.proxy.config silently. Which makes adding config support for pgBouncer much bigger change, requiring OpenEverest UI to support the field as well.

Let us think of any other necessary changes required for making pgBouncer config available.

[pvstekunov]

Can you just ignore spec.proxy.config section during reconciling?

Then I can create database cluster using percona everest and customize it on PerconaPgCluster level like it had been in 1.9.0 version?

[chilagrow]

Can you just ignore spec.proxy.config section during reconciling?

That would prevent spec.proxy.config from being silently removed. A concern with this approach is that it would add a field that is not visible in OpenEverest UI or update it, making UI not reflect the underlying field of CR.

Additionally DatabaseCluster CR's spec.proxy.config is used for other engines (MongoDB and MySQL), the field needs to be handled appropriately for other engines as well. This is something we find inflexible and we are addressing this in openeverest/openeverest#1769.

Then I can create database cluster using percona everest and customize it on PerconaPgCluster level like it had been in 1.9.0 version?

This is interesting, I was not aware, does this mean you've been able to configure spec.proxy.config prior version such as 1.9.0? 🤔

[pvstekunov]

Yes.

apiVersion: everest.percona.com/v1alpha1
kind: DatabaseCluster
metadata:
  labels:
    clusterName: backend
    monitoringConfigName: pmm
    podSchedulingPolicyName: everest-default-postgresql
  name: backend
spec:
  engine:
....
  proxy:
    expose:
      ipSourceRanges:
        - 10.0.0.0/8
      type: external
    replicas: 2
    resources:
      cpu: 500m
      memory: 100M
    type: pgbouncer
status:
  crVersion: 2.6.0
.....

apiVersion: pgv2.percona.com/v2
kind: PerconaPGCluster
metadata:
....
spec:
....
  crVersion: 2.6.0
  image: percona/percona-postgresql-operator:2.6.0-ppg17.4-postgres
....
  postgresVersion: 17
  proxy:
    pgBouncer:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 1
      config:
        global:
          client_tls_sslmode: allow
          default_pool_size: '600'
          max_client_conn: '1200'
      expose:
        loadBalancerSourceRanges:
          - 10.0.0.0/8
        type: LoadBalancer
      exposeSuperusers: true
      image: percona/percona-postgresql-operator:2.6.0-ppg17.4-pgbouncer1.24.0
...

[chilagrow]

Hi @pvstekunov, I found the commit which addresses the change in the behaviour e25a831. It was added in 1.10.0.

Reading the context in https://perconadev.atlassian.net/browse/EVEREST-2023, the very reason this fix was made is because if a parameter disappeared from DatabaseCluster, it was wrongly keeping it in PerconaPGCluster. This has also caused spec.proxy.config to reset it to empty default during reconciliation.

I don't think reverting the change made in 1.10.0 is ideal this case.

[pvstekunov]

Thanks for info.

Is there any way how to configure pgbouncer on PerconaPgCluster under control of everest 1.12/1.13?

[chilagrow]

@pvstekunov for 1.12/1.13 versions, unfortunately I can't think of how pgbouncer can be configured 😞.