danielhoherd opened a new issue, #56015:
URL: https://github.com/apache/airflow/issues/56015
### Official Helm Chart version
1.18.0 (latest released)
### Apache Airflow version
initContainers in scheduler, triggerer use inconsistent log volume configs
### Kubernetes Version
1.32
### Helm Chart configuration
_No response_
### Docker Image customizations
_No response_
### What happened
In the scheduler and triggerer, the `wait-for-airflow-migrations`
initContainer uses inconsistent `/usr/local/airflow/log` configurations (none)
while the main containers uses a tailored `/usr/local/airflow/log`
configuration. This creates an inconsistency between containers that run
airflow. In my specific use case, this is preventing me from adding a container
`securityContext.readOnlyRootFilesystem: true` because I am unable to create an
`emptyDir` for `/usr/local/airflow/logs` for the airflow components to write
to. If I set that config, I can't deploy because that volume already exists in
the `scheduler` container, but if I do not set it, the
`wait-for-airflow-migrations` fails because the logs dir is read-only.
### What you think should happen instead
All components in a pod that run airflow should have consistent volume
handling.
### How to reproduce
Install with these extra values:
```
scheduler:
extraVolumeMounts:
- mountPath: /usr/local/airflow/logs
name: airflow-logs
- mountPath: /tmp
name: tmp
extraVolumes:
- emptyDir: {}
name: airflow-logs
- emptyDir: {}
name: tmp
securityContexts:
containers:
readOnlyRootFilesystem: true
```
Also try it with the `airflow-logs` volume and volumeMount removed.
### Anything else
I am not reporting any problems with readOnlyRootFilesystem, just the volume
problem, which was found when configuring readOnlyRootFilesystem.
### Are you willing to submit PR?
- [x] 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
