prasadkris opened a new issue, #55405:
URL: https://github.com/apache/airflow/issues/55405
### Apache Airflow version
3.0.6
### If "Other Airflow 2 version" selected, which one?
_No response_
### What happened?
Greetings,
I’ve deployed Airflow on our self-hosted kubernetes cluster using the
official helm chart:
Chart: apache-airflow/airflow 1.18.0, Airflow: 3.0.2
Everything works well, but the deployments are noisy because the default
logging level is **INFO**. I’m trying to change it to **ERROR**.
I’ve tried both of the following and verified that airflow picks up the
values:
1. Environment variables (values.yaml)
```
extraEnv:
- name: AIRFLOW__LOGGING__LOGGING_LEVEL
value: "ERROR"
- name: AIRFLOW__LOGGING__CELERY_LOGGING_LEVEL
value: "ERROR"
- name: AIRFLOW__LOGGING__FAB_LOGGING_LEVEL
value: "ERROR"
```
2. `airflow.cfg` via chart config:
```
[logging]
logging_level = ERROR
```
Verification (inside pods):
```
airflow config list | grep -A4 'logging_level'
logging_level = ERROR
celery_logging_level = ERROR
fab_logging_level = ERROR
airflow config get-value logging logging_level
ERROR
```
Despite the above, the pod logs (e.g.,apiserver/scheduler/triggerer) still
contain `INFO` messages as seen below. I expected only `ERROR` and above.
```
k logs airflow-api-server-6bc6f976b7-w9mlg | tail
Defaulted container "api-server" out of: api-server,
wait-for-airflow-migrations (init)
INFO: 10.244.1.1:53666 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:53676 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:61652 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:61660 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:59274 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:59288 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:36436 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:36444 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:57346 - "GET /api/v2/version HTTP/1.1" 200 OK
INFO: 10.244.1.1:57352 - "GET /api/v2/version HTTP/1.1" 200 OK
pkr@node1 ~/airflow k logs airflow-triggerer-5d7b7bf6c-4q5v5 | tail
Defaulted container "triggerer" out of: triggerer, triggerer-log-groomer,
wait-for-airflow-migrations (init)
____________ _____________
____ |__( )_________ __/__ /________ __
____ /| |_ /__ ___/_ /_ __ /_ __ \_ | /| / /
___ ___ | / _ / _ __/ _ / / /_/ /_ |/ |/ /
_/_/ |_/_/ /_/ /_/ /_/ \____/____/|__/
[2025-09-08 10:30:56 +0000] [14] [INFO] Starting gunicorn 23.0.0
[2025-09-08 10:30:56 +0000] [14] [INFO] Listening at: http://[::]:8794 (14)
[2025-09-08 10:30:56 +0000] [14] [INFO] Using worker: sync
[2025-09-08 10:30:56 +0000] [15] [INFO] Booting worker with pid: 15
[2025-09-08 10:30:56 +0000] [16] [INFO] Booting worker with pid: 16
```
### What you think should happen instead?
After setting the logging level to ERROR as described above, container logs
should exclude INFO entries.
**What actually happens**:
Pods continue to emit INFO-level logs.
### How to reproduce
Deploy apache-airflow/airflow v1.18.0 (Airflow 3.0.2) with
`logging_level=ERROR` (via config or envVars). Verify in a pod that `airflow
config get-value logging logging_level` returns `ERROR`. Then check pod logs
(apiserver/triggerer etc..): INFO logs still appear.
### Operating System
Kubernetes, v1.32.0
### Versions of Apache Airflow Providers
_No response_
### Deployment
Official Apache Airflow Helm Chart
### Deployment details
_No response_
### Anything else?
_No response_
### Are you willing to submit PR?
- [ ] 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: commits-unsubscr...@airflow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
