FloChehab edited a comment on pull request #10584: URL: https://github.com/apache/airflow/pull/10584#issuecomment-715530418
Hello @mik-laj / @dimberman , I have the following proposition to make (inspired by https://github.com/codecentric/helm-charts/tree/master/charts/keycloak#using-a-secret-managed-by-the-chart) (i'll start from scratch again if this proposition sounds good to you): 1. Creating ConfigMaps & secrets from the chart: * adding the value `extraSecrets`: ```yaml extraSecrets: airflow-connections: stringData: AIRFLOW_CONN_GCP: '...' AIRFLOW_CONN_INTERNAL_DB: '...' other-secret-variables: stringData: SECRET_VAR_1: '...' SECRET_VAR_2: '...' ``` Which would yield 2 secrets: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: airflow-connections ... stringData: AIRFLOW_CONN_GCP: '...' AIRFLOW_CONN_INTERNAL_DB: '...' --- apiVersion: v1 kind: Secret type: Opaque metadata: name: other-secret-variables ... stringData: SECRET_VAR_1: '...' SECRET_VAR_2: '...' ``` Those secrets would be mounted with envFrom. * adding the value `extraConfigMaps`, with exactly the same idea. * For the support of the kubernetes executor, I'll add the envFrom in pod template and nothing more (so no support for previous airflow versions and the old configuration) This should be the best in terms of flexibility without getting too complex. 2. Adding the value `extraEnv` & `extraEnvFrom`, which would use the standard `env` & `envFrom` syntax (again not supporting the "old" KubernetesExecutor configuration). Given all of this and if we decide to drop the support for the old KubernetesExecutor configuration, we could remove the `env` and `secret` values from this chart (and do a lot cleaning in the helpers). ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
