[jira] [Created] (AIRFLOW-838) Race condition in LocalTaskJob
Alex Guziel created AIRFLOW-838: --- Summary: Race condition in LocalTaskJob Key: AIRFLOW-838 URL: https://issues.apache.org/jira/browse/AIRFLOW-838 Project: Apache Airflow Issue Type: Bug Reporter: Alex Guziel Priority: Minor Right now, a LocalTaskJob will terminate if the state is not "running" but only if it has observed that the state was "running" before. This could lead to a situation in which it never terminates although the state is not "running" if it was from "running" to another state before it could be observed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AIRFLOW-837) Clear task in the UI should state to None rather than deleting DB row
Alex Guziel created AIRFLOW-837: --- Summary: Clear task in the UI should state to None rather than deleting DB row Key: AIRFLOW-837 URL: https://issues.apache.org/jira/browse/AIRFLOW-837 Project: Apache Airflow Issue Type: Improvement Reporter: Alex Guziel Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AIRFLOW-836) The two endpoints /paused and queryview perform state-changing action over HTTP GET
Alex Guziel created AIRFLOW-836: --- Summary: The two endpoints /paused and queryview perform state-changing action over HTTP GET Key: AIRFLOW-836 URL: https://issues.apache.org/jira/browse/AIRFLOW-836 Project: Apache Airflow Issue Type: Bug Reporter: Alex Guziel Assignee: Alex Guziel These two endpoints change state and allow HTTP GET, allowing CSRF -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AIRFLOW-764) max_active_runs_per_dag not respected for DAGs triggered manually within a few seconds of one another
[ https://issues.apache.org/jira/browse/AIRFLOW-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Panzhin updated AIRFLOW-764: -- Attachment: Screen Shot 2017-02-03 at 7.53.06 PM.png Example of the bug - this has max runs per dag set to 4 and dag_concurrency set to 4. Both of those configuration options seem to have 0 effect. > max_active_runs_per_dag not respected for DAGs triggered manually within a > few seconds of one another > - > > Key: AIRFLOW-764 > URL: https://issues.apache.org/jira/browse/AIRFLOW-764 > Project: Apache Airflow > Issue Type: Bug > Components: core, executor >Affects Versions: Airflow 1.7.1.3 > Environment: debian linux, mysql with localexecutor >Reporter: Jeffrey Enns > Attachments: Screen Shot 2017-02-03 at 7.53.06 PM.png, test_dag.py, > test_dag_screen.png, test_job.sh, trigger_two.sh > > > Given the following configuration: > ``` > [core] > executor = LocalExecutor > max_active_runs_per_dag = 1 > parallelism = 20 > dag_concurrency = 1 > ``` > Even with `max_active_runs_per_dag=1`, it is possible to cause two (or more) > DAG runs to run in parallel by triggering the runs manually within a few > seconds/milliseconds of one another. Task Instances from the distinct DAG > runs will show as active in the “Task Instances” web view at the same time. > I only looked at the scheduler code briefly, but it looked as if a race > condition would be possible for manually triggered DAGs that could lead to > this behaviour. > I’ve attached a test DAG and two shell scripts I used to reliably reproduce > this behaviour. Put `test_dag.py` and `test_job.sh` in the DAGs folder, and > then run `trigger_two.sh` to reproduce the bug. > Also attached is a screenshot showing DAG runs (for the dag ‘race_dag’) > running in parallel after following the steps described immediately above > (note the execution date, start date, and end date for each TI). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (AIRFLOW-764) max_active_runs_per_dag not respected for DAGs triggered manually within a few seconds of one another
[ https://issues.apache.org/jira/browse/AIRFLOW-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15851975#comment-15851975 ] Alexander Panzhin edited comment on AIRFLOW-764 at 2/3/17 7:17 PM: --- This is a major problem when migrating to Airfllow. It's impossible to backfill manually DAGs and not manage them manually. This bug degrades the value of airflow down to a CRON with a nice UI. What's the point of a workflow management tool then? was (Author: jalexoid): This is a major problem when migrating to Airfllow. It's impossible to backfill manually DAGs and not manage them manually - what's the point of a workflow management tool then? > max_active_runs_per_dag not respected for DAGs triggered manually within a > few seconds of one another > - > > Key: AIRFLOW-764 > URL: https://issues.apache.org/jira/browse/AIRFLOW-764 > Project: Apache Airflow > Issue Type: Bug > Components: core, executor >Affects Versions: Airflow 1.7.1.3 > Environment: debian linux, mysql with localexecutor >Reporter: Jeffrey Enns > Attachments: test_dag.py, test_dag_screen.png, test_job.sh, > trigger_two.sh > > > Given the following configuration: > ``` > [core] > executor = LocalExecutor > max_active_runs_per_dag = 1 > parallelism = 20 > dag_concurrency = 1 > ``` > Even with `max_active_runs_per_dag=1`, it is possible to cause two (or more) > DAG runs to run in parallel by triggering the runs manually within a few > seconds/milliseconds of one another. Task Instances from the distinct DAG > runs will show as active in the “Task Instances” web view at the same time. > I only looked at the scheduler code briefly, but it looked as if a race > condition would be possible for manually triggered DAGs that could lead to > this behaviour. > I’ve attached a test DAG and two shell scripts I used to reliably reproduce > this behaviour. Put `test_dag.py` and `test_job.sh` in the DAGs folder, and > then run `trigger_two.sh` to reproduce the bug. > Also attached is a screenshot showing DAG runs (for the dag ‘race_dag’) > running in parallel after following the steps described immediately above > (note the execution date, start date, and end date for each TI). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AIRFLOW-764) max_active_runs_per_dag not respected for DAGs triggered manually within a few seconds of one another
[ https://issues.apache.org/jira/browse/AIRFLOW-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15851975#comment-15851975 ] Alexander Panzhin commented on AIRFLOW-764: --- This is a major problem when migrating to Airfllow. It's impossible to backfill manually DAGs and not manage them manually - what's the point of a workflow management tool then? > max_active_runs_per_dag not respected for DAGs triggered manually within a > few seconds of one another > - > > Key: AIRFLOW-764 > URL: https://issues.apache.org/jira/browse/AIRFLOW-764 > Project: Apache Airflow > Issue Type: Bug > Components: core, executor >Affects Versions: Airflow 1.7.1.3 > Environment: debian linux, mysql with localexecutor >Reporter: Jeffrey Enns > Attachments: test_dag.py, test_dag_screen.png, test_job.sh, > trigger_two.sh > > > Given the following configuration: > ``` > [core] > executor = LocalExecutor > max_active_runs_per_dag = 1 > parallelism = 20 > dag_concurrency = 1 > ``` > Even with `max_active_runs_per_dag=1`, it is possible to cause two (or more) > DAG runs to run in parallel by triggering the runs manually within a few > seconds/milliseconds of one another. Task Instances from the distinct DAG > runs will show as active in the “Task Instances” web view at the same time. > I only looked at the scheduler code briefly, but it looked as if a race > condition would be possible for manually triggered DAGs that could lead to > this behaviour. > I’ve attached a test DAG and two shell scripts I used to reliably reproduce > this behaviour. Put `test_dag.py` and `test_job.sh` in the DAGs folder, and > then run `trigger_two.sh` to reproduce the bug. > Also attached is a screenshot showing DAG runs (for the dag ‘race_dag’) > running in parallel after following the steps described immediately above > (note the execution date, start date, and end date for each TI). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AIRFLOW-835) SMTP Mail delivery fails with server using CRAM-MD5 auth
Joseph Harris created AIRFLOW-835:
-
Summary: SMTP Mail delivery fails with server using CRAM-MD5 auth
Key: AIRFLOW-835
URL: https://issues.apache.org/jira/browse/AIRFLOW-835
Project: Apache Airflow
Issue Type: Bug
Components: utils
Affects Versions: Airflow 1.7.1
Environment: https://hub.docker.com/_/python/ (debian:jessie +
python2.7 in docker)
Reporter: Joseph Harris
Priority: Minor
Traceback when sending email from smtp-server configured to offer CRAM-MD5 (in
all cases, tls included). This occurs because the configuration module returns
the password as a futures.types.newstr, instead of a plain str (see below for
gory details of why this breaks).
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/airflow/models.py", line 1308,
in handle_failure
self.email_alert(error, is_retry=False)
File "/usr/local/lib/python2.7/site-packages/airflow/models.py", line 1425,
in email_alert
send_email(task.email, title, body)
File "/usr/local/lib/python2.7/site-packages/airflow/utils/email.py", line
43, in send_email
return backend(to, subject, html_content, files=files, dryrun=dryrun)
File "/usr/local/lib/python2.7/site-packages/airflow/utils/email.py", line
79, in send_email_smtp
send_MIME_email(SMTP_MAIL_FROM, to, msg, dryrun)
File "/usr/local/lib/python2.7/site-packages/airflow/utils/email.py", line
95, in send_MIME_email
s.login(SMTP_USER, SMTP_PASSWORD)
File "/usr/local/lib/python2.7/smtplib.py", line 607, in login
(code, resp) = self.docmd(encode_cram_md5(resp, user, password))
File "/usr/local/lib/python2.7/smtplib.py", line 571, in encode_cram_md5
response = user + " " + hmac.HMAC(password, challenge).hexdigest()
File "/usr/local/lib/python2.7/hmac.py", line 75, in __init__
self.outer.update(key.translate(trans_5C))
File "/usr/local/lib/python2.7/site-packages/future/types/newstr.py", line
390, in translate
if ord(c) in table:
TypeError: 'in ' requires string as left operand, not int
SMTP configs:
[email]
email_backend = airflow.utils.email.send_email_smtp
[smtp]
smtp_host = {a_smtp_server}
smtp_port = 587
smtp_starttls = True
smtp_ssl = False
smtp_user = {a_username}
smtp_password = {a_password}
smtp_mail_from = {a_email_addr}
*Gory details
If the server offers CRAM-MD5, smptlib prefers this by default, and will try to
use hmac.HMAC to hash the password:
https://hg.python.org/cpython/file/2.7/Lib/smtplib.py#l602
https://hg.python.org/cpython/file/2.7/Lib/smtplib.py#l571
But if the password is a newstr, newstr.translate expects a dict mapping
instead of str, and raises an exception.
https://hg.python.org/cpython/file/2.7/Lib/hmac.py#l75
All of this occurs after a successful SMTP.ehlo(), so it's probably not crap
container networking
Could be resolved by passing the smtp password as a futures.types.newbytes, as
this behaves as expected:
from future.types import newstr, newbytes
import hmac
# Make str / newstr types
test = 'a_string'
test_newstr = newstr(test)
test_newbytes = newbytes(test)
msg = 'future problems'
# Test 1 - Try to do a HMAC:
# fine
hmac.HMAC(test, msg)
# fails horribly
hmac.HMAC(test_newstr, msg)
# is completely fine
hmac.HMAC(test_newbytes, msg)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AIRFLOW-834) get_dep_statuses raises PendingDeprecationWarning in Python 3.5
Marek Baczyński created AIRFLOW-834:
---
Summary: get_dep_statuses raises PendingDeprecationWarning in
Python 3.5
Key: AIRFLOW-834
URL: https://issues.apache.org/jira/browse/AIRFLOW-834
Project: Apache Airflow
Issue Type: Bug
Affects Versions: Airflow 1.8, 1.8.0b5
Reporter: Marek Baczyński
Priority: Minor
{noformat}
venv/src/airflow/airflow/ti_deps/deps/base_ti_dep.py:94:
PendingDeprecationWarning: generator '_get_dep_statuses' raised StopIteration
for dep_status in self._get_dep_statuses(ti, session, dep_context):
{noformat}
fix would be to change these into plain return
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
