malov opened a new issue, #26623:
URL: https://github.com/apache/airflow/issues/26623
### Apache Airflow version
Other Airflow 2 version
### What happened
Using Bitnami Airflow image, I'm upgrading Airflow from 2.1.4 to 2.2.0,
running on Kubernetes cluster. During upgrade no changes to environment is
made: kubernets cluster is the same, database is the same, Helm chart used is
the same. Docker images are custom build due to company's restrictions, but the
only change in build process is what Airflow version is used.
What happened:
– DB upgrade initially generated errors due to different schema
(task_instantses and dug_runs tables), but upon examining, they were harmless:
records were apparantly from some test some months ago
– scheduler and web containers started without errors, found all dags and
parsed them correctly
– attmept to start test dag (which uses Bash operator and prints hello
world) failed with errors:
```
[2022-09-19 18:03:26,111] {dagbag.py:500} INFO - Filling up the DagBag from
/opt/bitnami/***/dags/test_dag.py
Traceback (most recent call last):
File "/opt/bitnami/airflow/venv/bin/airflow", line 8, in <module>
sys.exit(main())
File
"/opt/bitnami/airflow/venv/lib/python3.8/site-packages/airflow/__main__.py",
line 48, in main
args.func(args)
File
"/opt/bitnami/airflow/venv/lib/python3.8/site-packages/airflow/cli/cli_parser.py",
line 48, in command
return func(*args, **kwargs)
File
"/opt/bitnami/airflow/venv/lib/python3.8/site-packages/airflow/utils/cli.py",
line 92, in wrapper
return f(*args, **kwargs)
File
"/opt/bitnami/airflow/venv/lib/python3.8/site-packages/airflow/cli/commands/task_command.py",
line 276, in task_run
dag = get_dag(args.subdir, args.dag_id)
File
"/opt/bitnami/airflow/venv/lib/python3.8/site-packages/airflow/utils/cli.py",
line 192, in get_dag
raise AirflowException(
airflow.exceptions.AirflowException: Dag 'test_dag' could not be found;
either it does not exist or it failed to parse.
```
So, apparently worker pod found a dag, as it is indicated by first line, but
then failed to find it again.
From the scheduler log:
```
[2022-09-22 12:28:54,476] {kubernetes_executor.py:531} INFO - Add task
TaskInstanceKey(dag_id='test_dag', task_id='print_current_date',
run_id='scheduled__2022-09-21T15:35:00+00:00', try_number=1) with command
['airflow', 'tasks', 'run', 'test_dag', 'print_current_date',
'scheduled__2022-09-21T15:35:00+00:00', '--local', '--subdir',
'DAGS_FOLDER/test_dag.py'] with executor_config {}
```
Checking currently running instance of 2.1.4 Airflow, I see that
corresponding line there is
```
[2022-09-22 12:28:54,476] {kubernetes_executor.py:531} INFO - Add task
TaskInstanceKey(dag_id='test_dag', task_id='print_current_date',
run_id='scheduled__2022-09-21T15:35:00+00:00', try_number=1) with command
['airflow', 'tasks', 'run', 'test_dag', 'print_current_date',
'scheduled__2022-09-21T15:35:00+00:00', '--local', '--subdir',
'/airflow-workflow/dags/test_dag.py'] with executor_config {}
```
So, subdirs argument is resolved correctly, and test_dag runs fine.
I think this is a reason for a failure - that command to run test_dag
doesn't resolve "subdirs" parameter correctly, but I don't know how to fix it:
1. "dags_folder" is set correctly in web and scheduler airflow.cfg
2. AIRFLOW_DAGS_DIR is set correctly in web and scheduler
3. It's difficult to get information from crashed worker pods, but they are
built using same scripts, so I assume they are have the same settings.
### What you think should happen instead
Test dag should be run by worker pod and print "hellow world" as it does in
setup with Airflow 2.1.4
### How to reproduce
_No response_
### Operating System
Docker image uses:
### Versions of Apache Airflow Providers
_No response_
### Deployment
Other 3rd-party 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
