EliMor commented on issue #17489:
URL: https://github.com/apache/airflow/issues/17489#issuecomment-899623808
Apologies. I'm a strange person and I struggle to communicate clearly at
times.
This is what I am asking.
Is it correct that there are currently several ways of providing, in our
case, the db connection details;
```
metadataConnection:
user: airflow
pass: top secret password
protocol: postgresql
host: fakedb.us-west-2.rds.amazonaws.com
port: 5432
db: postgres
sslmode: disable
```
And
```
extraEnv: AIRFLOW__CORE__SQL_ALCHEMY_CONN*
```
And
mounting ```airflow.cfg``` from a secret or (configmap?) directly
If the above are true and if the argument is that the use of the helm chart
should be 'intuitively' or 'naturally' the way Airflow does things (I'm
extrapolating from your statement that kube should bend to Airflow), then it
seems that the chart should be structured to look as close to Airflow directly
as possible.
Ie. perhaps instead of a 'metadataConnection,' etc., there should just be an
area that engages with this behavior:
> The universal order of precedence for all configuration options is as
follows:
> set as an environment variable (AIRFLOW__CORE__SQL_ALCHEMY_CONN)
> set as a command environment variable (AIRFLOW__CORE__SQL_ALCHEMY_CONN_CMD)
> set as a secret environment variable
(AIRFLOW__CORE__SQL_ALCHEMY_CONN_SECRET)
> set in airflow.cfg
> command in airflow.cfg
> secret key in airflow.cfg
> Airflow’s built in defaults
Please let me know if I'm making more bad assumptions here.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
