Glad you want to contribute! This is a great approach when you see something that you miss!
I personally think it's best to go for 1) - this makes the environments between various components more consistent and might prevent other problems - I think there is a silen, never documented assumption we have that "AIRFLOW_HOME" is writeable for all airflow commands. Others might have different preferences though. But a suggestion: rather than opening discussion in the devlist (it has rather low-volume, important discussions and conclusions) use Github Discussions or even better - propose a PR and relevant people can discuss it there. Discussing the approach while seeing the code is always better and in this case the change is small enough that just `creating -> discussions -> changing after` approach. For small changes like that, the latter is usually faster than making extensive discussion upfront before attempting a PR. And not everyone in devlist is interested in such nitty-gritty-implementation-details of Helm Chart :) J. On Fri, Oct 28, 2022 at 1:40 PM <[email protected]> wrote: > > Hi everyone, > > > > First timer here. > > We have readOnlyRootFilesystem enforced in our Kubernetes cluster, but we do > not want to set webserverConfig in values.yaml to be able to have proper > linting and autocompletion. Unfortunately, the chart is not adapted to this > use-case because the generated config file (if webserverConfig is set) is > mounted only in the webserver pod, and all other pods try to generate it when > they start (including init containers and sidecars). Of course, as the > filesystem is read-only, this fails, and the pods can’t start. > > > > I would like to create a PR to fix this issue. There would be 2 obvious ways: > > Add the extraVolumeMounts to init and sidecar containers (for scheduler, > triggerer, webserver and workers), so that users can mount a writable > directory to airflowHome, where the webserver_config.py file can be created > Add an option to specify a webserverConfigConfigmapName that would be mounted > to all containers at airflow_webserver_config_path and supersede any > specified webserverConfig. > > A third way would be to add logic to parse the securityContext and add a > specific empty volume to host the webserver config but recent changes > introduced or to be introduced via #25985, #25530 and #24588 makes this > cumbersome and error-prone. > > > > I would like to pursue option 2 to favor simplicity of use and to remain in > line with past decisions not to add volumes that only the main container > should have to init and sidecar containers. Does the community prefer any > other implementation (option 1, 3 or any other that I have not listed) or > have any suggestions ? > > > > Cheers, > > -- > > Jules Triomphe > > Data, Analytics & AI Engineer > Data, Analytics & AI > Swisscom > > +41 79 382 04 07 > > Swisscom (Schweiz) AG > EPFL Innovation Park, Building F, 3rd Floor > 1015 Lausanne > > Ready for the future? https://swisscom.ch/ai > >
