ME
Сам сабдаг тип ещё в процессе, причём третья таска эта по времени начала оказалась запущена до предыдущих:
Size: a a a
2020 December 11
ME
Никто такого не встречал? 1.10.13, Celery
ME
Хм, в логе ошибка странная какая-то:
[2020-12-11 00:05:39,164] {taskinstance.py:662} INFO - Dependencies not met for <TaskInstance: ..... 2020-12-10T00:00:00+00:00 [scheduled]>, dependency 'Task Instance State' FAILED: Task is in the 'scheduled' state which is not a valid state for execution. The task must be cleared in order to be run.
[2020-12-11 00:05:39,294] {local_task_job.py:90} INFO - Task is not able to be runAB
Какой trigger_rule у таса?
ME
дефолтный, all_success вроде
AB
retry?
ME
"retries": 0,
ME
там ещё десяток дагов с такой конфигурацией, свалился только один первый раз. Перезапуск сабдага проблему решил. Очень странно, похоже на какой-то баг
ME
Тип шедулер почему-то его в шедулед перевёл до выполнения предыдущих, а когда пришёл к нему, статус неверный и всё упало
AB
Да, мне тоже так показалось. Может, по максимальному количеству тасков или еще почему-то встали в очередь, но потом из нее не вышли.
A
Всем привет!
Есть в Airflow возможность централизованно хранить параметры расписания DAG'ов (start_date, schedule_interval)?
В идеале, чтобы это хранилище не запрашивать каждый heartbeat?
Есть в Airflow возможность централизованно хранить параметры расписания DAG'ов (start_date, schedule_interval)?
В идеале, чтобы это хранилище не запрашивать каждый heartbeat?
эти значения можно хранить где-нибудь и кэшировать в Variables вместе с update_time. функция которая достает эти значения из Variables проверяет update_time и если это было давно то лезет в хранилище и обновляет
2020 December 12
AB
Variables же тоже в БД какой-то хранятся. Можно и каждый раз в хранилище параметров лазить, неочевидна разница.
Разве что можно посмотреть переменные среды AIRFLOW_VAR_*, к которым доступ через Variables, или просто через os.environ.
Но это сложно будет поддерживать, поэтому пока ищу варианты.
Разве что можно посмотреть переменные среды AIRFLOW_VAR_*, к которым доступ через Variables, или просто через os.environ.
Но это сложно будет поддерживать, поэтому пока ищу варианты.
GB
Variables же тоже в БД какой-то хранятся. Можно и каждый раз в хранилище параметров лазить, неочевидна разница.
Разве что можно посмотреть переменные среды AIRFLOW_VAR_*, к которым доступ через Variables, или просто через os.environ.
Но это сложно будет поддерживать, поэтому пока ищу варианты.
Разве что можно посмотреть переменные среды AIRFLOW_VAR_*, к которым доступ через Variables, или просто через os.environ.
Но это сложно будет поддерживать, поэтому пока ищу варианты.
Ну никак не обойдёшь то, что поллятся файлы с дагами.
Ты можешь выставить
Лучше скажи, какие есть причины для того, что ты вообще ищешь варианты, и можно будет подсказать
Ты можешь выставить
min_file_process_interval побольше (дефолтный чуть ли не 1 секунда), и тогда вся логика, которая описана внутри файлов с дагами, но не в тасках, будет выполняться реже. Потому и считается правильным все задачи выполнять всё-таки в операторах. Лучше скажи, какие есть причины для того, что ты вообще ищешь варианты, и можно будет подсказать
GB
Ну и Variables у тебя так и так в metadb Airflow, это самый бескровный вариант (ну и XCOM, но он не всегда подходит), если нужно что-то передавать таскам
AB
Хотим параметризовать даги. Думаем, как лучше.
M
Хотим параметризовать даги. Думаем, как лучше.
а чем плох yaml конфиг на диске?