s

в конце

поправил да

разве можно достать из indexing_contents. xcom из get_telegram_content?

его же нет в списке upstream_task_ids

то есть мне приходиться еще в branch повторно пуллить данные
s3_urls = task_instance.xcom_pull(task_ids="get_telegram_content")
print(s3_urls)
if len(s3_urls) == 0:
   return 'exiting'

task_instance.xcom_push(key="return_value", value=s3_urls)

@savelyev_an проблема была в опечатке, спасибо)

Я вообще не уточняю названия тасок, когда из xcom достаю. Просто по ключу

И еще вопрос, как увеличить время между
webserver_1  | [2020-09-09 13:10:02,038] {dagbag.py:417} INFO - Filling up the DagBag from /opt/airflow/dags
У меня динамически создаются даги и мне вообще не нужно, что бы он сам запускал рефреш

Смотри конфиг

я так понял
AIRFLOW__CORE__DAG_FILE_PROCESSOR_TIMEOUT=36000

но, что то изменений не заметил

Таск завершается со статус кодом -9, как в https://stackoverflow.com/questions/62015555/airflow-task-info-task-exited-with-return-code-9. Есть такой комментарий:

-9 indicates the system killed the process, most likely as the DataFrame consumed too much memory. Best advice is to rewrite your script to use less memory or to scale up the machine running Airflow (if possible).

А как скейлить докер контейнер или машинку, как дебажить даг?

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) could not translate host name "postgres" to address: Temporary failure in name resolution

и вот такая тема еще иногда вылезает

-9 indicates the system killed the process, most likely as the DataFrame consumed too much memory. Best advice is to rewrite your script to use less memory or to scale up the machine running Airflow (if possible).

посмотрите логи оом-киллера
grep -i 'killed process' /var/log/messages

Там таких логов нет, но есть такие:

alternatives.log  apt  btmp  dpkg.log  faillog lastlog  wtmp

В остальных такого нет, но идею понял, спасибо

Всем привет! Только-только решился переехать с pentaho на airflow (пока объёмы позволяют переехать). Задумался над тем как свой будущий ETL-пайплайн (со всеми зависимостями python) перетащить с машины локальной на сервак где всё добро будет выполняться по расписанию. А задумался, потому что изначально планировал закинуть пайплайн в докер. Мимо проскочила инфа, что пихать airflow в докер не лучшая идея из за не всегда корректной работы оного с датой/временем. Опыта нету пока поэтому спросить хочу коммунити. Подскажите пожалуйста действительно ли это не лучшая идея, и какие тут вообще могут быть варианты с упаковкой зависимостей и переноса всего этого? Можно ссылкой швырнуть =)

У нас вроде норм в докере, с датой точно проблем не было...

Везде UTC