Repository: incubator-airflow
Updated Branches:
  refs/heads/v1-8-stable a9eff38f5 -> 67bb4bbf9


Add pool upgrade issue description

(cherry picked from commit e63cb1fced9517397b7db9e2849bf01fcca63902)
Signed-off-by: Bolke de Bruin <[email protected]>


Project: http://git-wip-us.apache.org/repos/asf/incubator-airflow/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-airflow/commit/4612bc36
Tree: http://git-wip-us.apache.org/repos/asf/incubator-airflow/tree/4612bc36
Diff: http://git-wip-us.apache.org/repos/asf/incubator-airflow/diff/4612bc36

Branch: refs/heads/v1-8-stable
Commit: 4612bc36f15bd70d5abdbdf9de680522215fc4af
Parents: a9eff38
Author: Bolke de Bruin <[email protected]>
Authored: Thu Feb 9 16:10:17 2017 +0100
Committer: Bolke de Bruin <[email protected]>
Committed: Thu Feb 9 16:13:02 2017 +0100

----------------------------------------------------------------------
 UPDATING.md | 6 ++++++
 1 file changed, 6 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-airflow/blob/4612bc36/UPDATING.md
----------------------------------------------------------------------
diff --git a/UPDATING.md b/UPDATING.md
index 337b711..b56aca8 100644
--- a/UPDATING.md
+++ b/UPDATING.md
@@ -14,6 +14,12 @@ Systemd unit files have been updated. If you use systemd 
please make sure to upd
 
 > Please note that the webserver does not detach properly, this will be fixed 
 > in a future version.
 
+### Tasks not starting although dependencies are met due to stricter pool 
checking
+Airflow 1.7.1 has issues with being able to over subscribe to a pool, ie. more 
slots could be used than were
+available. This is fixed in Airflow 1.8.0, but due to past issue jobs may fail 
to start although their
+dependencies are met after an upgrade. To workaround either temporarily 
increase the amount of slots above
+the the amount of queued tasks or use a new pool.
+
 ### Less forgiving scheduler on dynamic start_date
 Using a dynamic start_date (e.g. `start_date = datetime.now()`) is not 
considered a best practice. The 1.8.0 scheduler
 is less forgiving in this area. If you encounter DAGs not being scheduled you 
can try using a fixed start_date and

Reply via email to