You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2021/11/16 20:58:34 UTC

[GitHub] [airflow] freget opened a new issue #19627: Providing a metadata secret conflicts with the use of pgbouncer

freget opened a new issue #19627:
URL: https://github.com/apache/airflow/issues/19627


   ### Official Helm Chart version
   
   1.3.0 (latest released)
   
   ### Apache Airflow version
   
   2.2.1
   
   ### Kubernetes Version
   
    1.20.9
   
   ### Helm Chart configuration
   
   ```
   data:
     # If secret names are provided, use those secrets
     metadataSecretName: airflow-db-secret
     resultBackendSecretName: airflow-db-secret
   
   pgbouncer:
     # Enable PgBouncer
     enabled: true
   ```
   
   ### Docker Image customisations
   
   _No response_
   
   ### What happened
   
   If  the airflow database connections are configured via a predefined secret (instead of setting `data.metadataConnection.*`) and using pbouncer at the same time (`pgbouncer.enabled: true`), a few problems arise:
   
   - In the scheduler and worker configuration, the `AIRFLOW_CONN_AIRFLOW_DB` and `AIRFLOW__CELERY__RESULT_BACKEND` are set directly to the connection string within the secret. This means, pgbouncer is bypassed and the connection to the database is made directy. We might correct this if we change the secret value to point to pgbouncer (i.e. `postgresql://user:password@airflow-pgbouncer.namespace.svc.cluster.local:6543/airflow-result-backend`). This requires hardcoding pgbouncer connection information into the secret, though. 
   - Within pgbouncer, `/etc/pgbouncer/users.txt` is empty (as we do not have a username and password available)
   -  metrics-exporter of pgbouncer has the `DATABASE_URL` set to `postgresql://%3Cno+value%3E:%3Cno+value%3E@127.0.0.1:6543/pgbouncer?sslmode=disable`.
   
   In summary, it is not possible to use pgbouncer with a submitted secret name. 
   
   ### What you expected to happen
   
   _No response_
   
   ### How to reproduce
   
   _No response_
   
   ### Anything else
   
   I already solved this by a major refactoring of the whole secret mechanism.
   Instead of providing the connection string directly, we could provide a username and a password. Those might be mounted as environment variables and then used to replace the faulty secrets.
   
   To make this bulletproof for all situations (including keeping the connection string approach if no pgbouncer is enabled) is a bit more complicated, though. 
   
   ### Are you willing to submit PR?
   
   - [ ] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org