Datkros commented on pull request #9695: URL: https://github.com/apache/airflow/pull/9695#issuecomment-657443814
> How do you benefit from changing your environment configuration? I am afraid that in a moment we will have in Helm copies of all options, but with a different interface and worse documentation. > https://github.com/apache/airflow/blob/40af9f08b450a40f115c9cb411b7ad905ab555ba/chart/values.yaml#L94-L97 > > An additional option in Helm Chart is useful when changing options in Airflow also requires changing elsewhere in Helm. An example here: > https://github.com/apache/airflow/pull/9778/files > > Configuring logging would be useful if the bucket were automatically configured at the same time. You can do it using the product below for GCP. > https://github.com/GoogleCloudPlatform/k8s-config-connector It benefits me because we'd be managing multiple airflow instances with different logging folders and credentials, this is specially important if it's across multiple teams / use cases, as some of them would have different isolated environment configuration (prod v staging i.e). I could always overwrite it as an env var as you mentioned, but we'd lose visibility on what's the current configuration running by just looking at the source. In this particular use case, everything is in AWS, so it'd be preferable to use terraform / cloudformation (or maybe someone else would prefer Puppet, Chef, or ansible) to better manage those bucket and credential resources instead of locking you into a solution through having the helm release create the buckets as well. This is what happens right now by having the helm chart depend on the k8s secret creation, as you cannot choose somewhere else to store DB DNS secrets, locking you into that solution. Essentially, one big issue of having both <env> and the configmap is that your entire configuration becomes disjointed, being partially loaded through a .cfg, and from environment variables. It becomes hard to track what gets changed where, what is being already provided to you. Not having a single entry source makes it difficult for end users to see the full picture of their airflow configuration without having to dig through the code. This is why I chose to modify the configmap, as I believe that maybe it should be exposed through here since airflow already has templates for how this configuration would look like. ---------------------------------------------------------------- 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]
