Skip to content

Conversation

@ultrabug
Copy link
Contributor

Dear Airflow maintainers,

Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!

JIRA

Description

  • Here are some details about my PR, including screenshots of any UI changes:

The scheduler's DAG run creation logic can be tricky and one is
easily confused with the start_date + interval
and period end scheduling way of thinking.

It would ease airflow's usage to add a next_scheduler_run property to DAGs
so that we can very easily see the (un)famous period end after which
the scheduler will create a new DAG run for our workflows.

These patches add such a field to the dag table and the DagModel
property + scheduler logic to update it when calculated.

Tests

  • My PR adds the following unit tests OR does not need testing for this extremely good reason:

Tests are proposed along this patches.

Commits

  • My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":
    1. Subject is separated from body by a blank line
    2. Subject is limited to 50 characters
    3. Subject does not end with a period
    4. Subject uses the imperative mood ("add", not "adding")
    5. Body wraps at 72 characters
    6. Body explains "what" and "why", not "how"

The scheduler's DAG run creation logic can be tricky and one is
easily confused with the start_date + interval
and period end scheduling way of thinking.

It would ease airflow's usage to add a *next_scheduler_run* property to DAGs
so that we can very easily see the (un)famous *period end* after which
the scheduler will create a new DAG run for our workflows.

These patches add such a field to the *dag* table and the DagModel
property + scheduler logic to update it when calculated.
@codecov-io
Copy link

Codecov Report

Merging #2457 into master will increase coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2457      +/-   ##
==========================================
+ Coverage    69.4%   69.42%   +0.02%     
==========================================
  Files         146      146              
  Lines       11289    11297       +8     
==========================================
+ Hits         7835     7843       +8     
  Misses       3454     3454
Impacted Files Coverage Δ
airflow/models.py 87.27% <100%> (+0.03%) ⬆️
airflow/jobs.py 76.37% <100%> (+0.04%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 751e936...c0a19f2. Read the comment docs.

@bolkedebruin
Copy link
Contributor

Please explain where the user wants to see this and how this is exposed? We already make the following schedule available in templates for operators as "next_execution_date"

@ultrabug
Copy link
Contributor Author

Thanks for your reply @bolkedebruin.

The 2 main reasons are:

  • Make it possible for this valuable information to be exposed on the web interface (see screenshot) so you can access it in a non programmatic way
  • This information is very handy when you deploy your DAG for a later execution and want to make sure of the exact time after which it will be triggered.

To sum it up, having the "next_execution_date" in the code is cool but your code has to be executed in the first hand to get this information + it is not informative on a user / monitoring perspective.

Adding this on the dag table allows to immediately have this information available on the web UI like this:
2017-07-19-190800_712x654_scrot

@saguziel
Copy link
Contributor

The dagbag has access to the webserver

@bolkedebruin
Copy link
Contributor

and thus can derive this programmatically. No need for a scheduler and database change.

@ultrabug
Copy link
Contributor Author

I'm sorry if this sounds obvious to you but would you mind giving a bit more details please guys?

Let's say I want this information displayed on the web UI, how would I proceed and avoid that schema change?

@ultrabug
Copy link
Contributor Author

Also, would you be interested/okay for a PR adding this field in the web UI please?

@ultrabug
Copy link
Contributor Author

I am closing this PR in favour to #2460 which implements the desired information without a schema change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants