You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by ka...@apache.org on 2021/03/18 12:54:33 UTC
[airflow] branch master updated: Replaces 1.10.14 with 1.10.15
where needed (#14866)
This is an automated email from the ASF dual-hosted git repository.
kaxilnaik pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/master by this push:
new 3f61df1 Replaces 1.10.14 with 1.10.15 where needed (#14866)
3f61df1 is described below
commit 3f61df11e7e81abc0ac4495325ccb55cc1c88af4
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Thu Mar 18 13:54:16 2021 +0100
Replaces 1.10.14 with 1.10.15 where needed (#14866)
---
BREEZE.rst | 4 +-
breeze-complete | 1 +
dev/README_RELEASE_AIRFLOW_UPGRADE_CHECK.md | 2 +-
dev/check_files.py | 4 +-
docs/apache-airflow/production-deployment.rst | 2 +-
docs/apache-airflow/upgrade-check.rst | 4 +-
docs/apache-airflow/upgrading-to-2.rst | 28 ++--
docs/docker-stack/build-arg-ref.rst | 212 ++++++++++++++++++++++++++
8 files changed, 235 insertions(+), 22 deletions(-)
diff --git a/BREEZE.rst b/BREEZE.rst
index 8323b0f..023df8b 100644
--- a/BREEZE.rst
+++ b/BREEZE.rst
@@ -1313,7 +1313,7 @@ This is the current syntax for `./breeze <./breeze>`_:
One of:
- 2.0.0 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
+ 2.0.0 1.10.15 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
When 'none' is used, you can install airflow from local packages. When building image,
airflow package should be added to 'docker-context-files' and
@@ -2556,7 +2556,7 @@ This is the current syntax for `./breeze <./breeze>`_:
One of:
- 2.0.0 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
+ 2.0.0 1.10.15 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
When 'none' is used, you can install airflow from local packages. When building image,
airflow package should be added to 'docker-context-files' and
diff --git a/breeze-complete b/breeze-complete
index cb6bb3a..310ca37 100644
--- a/breeze-complete
+++ b/breeze-complete
@@ -58,6 +58,7 @@ _breeze_allowed_installation_methods=". apache-airflow"
_breeze_allowed_install_airflow_versions=$(cat <<-EOF
2.0.0
+1.10.15
1.10.14
1.10.12
1.10.11
diff --git a/dev/README_RELEASE_AIRFLOW_UPGRADE_CHECK.md b/dev/README_RELEASE_AIRFLOW_UPGRADE_CHECK.md
index 7970ad1..71d773d 100644
--- a/dev/README_RELEASE_AIRFLOW_UPGRADE_CHECK.md
+++ b/dev/README_RELEASE_AIRFLOW_UPGRADE_CHECK.md
@@ -252,7 +252,7 @@ this RC are described in
<https://github.com/apache/airflow/blob/master/dev/README_RELEASE_AIRFLOW.md#verify-release-candidates-by-contributors>,
but again, this time it is a little bit different.
-To actually use this command you will need apache-airflow 1.10.14
+To actually use this command you will need apache-airflow 1.10.15
Please note that the version number inside the archives exclude the
`rcX` string, so it's now simply 1.3.0. This will allow us to rename
diff --git a/dev/check_files.py b/dev/check_files.py
index 5aed604..7fe9a13 100644
--- a/dev/check_files.py
+++ b/dev/check_files.py
@@ -23,7 +23,7 @@ import click as click
from rich import print
BACKPORTS_DOCKER = """\
-FROM apache/airflow:1.10.14
+FROM apache/airflow:1.10.15
# Install backports
{}
@@ -45,7 +45,7 @@ RUN pip install "apache-airflow=={}"
"""
DOCKER_UPGRADE = """\
-FROM apache/airflow:1.10.14
+FROM apache/airflow:1.10.15
# Install upgrade-check
RUN pip install "apache-airflow-upgrade-check=={}"
diff --git a/docs/apache-airflow/production-deployment.rst b/docs/apache-airflow/production-deployment.rst
index 0f4dfaa..0fa9095 100644
--- a/docs/apache-airflow/production-deployment.rst
+++ b/docs/apache-airflow/production-deployment.rst
@@ -544,7 +544,7 @@ The following build arguments (``--build-arg`` in docker build command) can be u
| | | 1.10.* installation. In case of building |
| | | specific version you want to point it |
| | | to specific tag, for example |
-| | | ``constraints-1.10.14``. |
+| | | ``constraints-1.10.15``. |
+------------------------------------------+------------------------------------------+------------------------------------------+
| ``INSTALL_PROVIDERS_FROM_SOURCES`` | ``false`` | If set to ``true`` and image is built |
| | | from sources, all provider packages are |
diff --git a/docs/apache-airflow/upgrade-check.rst b/docs/apache-airflow/upgrade-check.rst
index 2a18377..18bbec0 100644
--- a/docs/apache-airflow/upgrade-check.rst
+++ b/docs/apache-airflow/upgrade-check.rst
@@ -33,7 +33,7 @@ a period of time and specifically only for upgrading from Airflow 1.10 releases
While there has been a lot of work put into making this upgrade as easy as possible, there are some
changes which are compatible between Airflow 1.10 and Airflow 2.0. In order to make this as simple to
navigate, we recommend that people first upgrade to the latest release in the 1.10 series (at the
-time of writing: 1.10.14) and then to download this package and run the script as detailed below.
+time of writing: 1.10.15) and then to download this package and run the script as detailed below.
.. note::
@@ -173,7 +173,7 @@ statement for the Python Operator to be as follows will make this DAG work in Ai
from airflow.operators.python import PythonOperator
-However, at the time of writing, this is incompatible in Airflow 1.10.14. So, this change
+However, at the time of writing, this is incompatible in Airflow 1.10.15. So, this change
can only be made while moving to Airflow 2.0.
diff --git a/docs/apache-airflow/upgrading-to-2.rst b/docs/apache-airflow/upgrading-to-2.rst
index b1b3a6b..96293ae 100644
--- a/docs/apache-airflow/upgrading-to-2.rst
+++ b/docs/apache-airflow/upgrading-to-2.rst
@@ -37,26 +37,26 @@ For a list of breaking changes between Python 2 and Python 3, please refer to th
from the CouchBaseDB team.
-Step 2: Upgrade to Airflow 1.10.14 (a.k.a our "bridge" release)
+Step 2: Upgrade to Airflow 1.10.15 (a.k.a our "bridge" release)
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-To minimize friction for users upgrading from Airflow 1.10 to Airflow 2.0 and beyond, Airflow 1.10.14 "a bridge release" has
-been created. This is intended to be the final 1.10 feature release. Airflow 1.10.14 includes support for various features
+To minimize friction for users upgrading from Airflow 1.10 to Airflow 2.0 and beyond, Airflow 1.10.15 "a bridge release" has
+been created. This is intended to be the final 1.10 feature release. Airflow 1.10.15 includes support for various features
that have been backported from Airflow 2.0 to make it easy for users to test their Airflow
environment before upgrading to Airflow 2.0.
We strongly recommend that all users upgrading to Airflow 2.0, first
-upgrade to Airflow 1.10.14 and test their Airflow deployment and only then upgrade to Airflow 2.0.
+upgrade to Airflow 1.10.15 and test their Airflow deployment and only then upgrade to Airflow 2.0.
The Airflow 1.10.x release tree will be supported for six months from Airflow 2.0 release date.
-Features in 1.10.14 include:
+Features in 1.10.15 include:
-1. Most breaking DAG and architecture changes of Airflow 2.0 have been backported to Airflow 1.10.14. This backward-compatibility does not mean
-that 1.10.14 will process these DAGs the same way as Airflow 2.0. Instead, this means that most Airflow 2.0
-compatible DAGs will work in Airflow 1.10.14. This backport will give users time to modify their DAGs over time
+1. Most breaking DAG and architecture changes of Airflow 2.0 have been backported to Airflow 1.10.15. This backward-compatibility does not mean
+that 1.10.15 will process these DAGs the same way as Airflow 2.0. Instead, this means that most Airflow 2.0
+compatible DAGs will work in Airflow 1.10.15. This backport will give users time to modify their DAGs over time
without any service disruption.
-2. We have also backported the updated Airflow 2.0 CLI commands to Airflow 1.10.14, so that users can modify their scripts
+2. We have also backported the updated Airflow 2.0 CLI commands to Airflow 1.10.15, so that users can modify their scripts
to be compatible with Airflow 2.0 before the upgrade.
3. For users of the KubernetesExecutor, we have backported the ``pod_template_file`` capability for the KubernetesExecutor
@@ -73,7 +73,7 @@ section of your ``airflow.cfg``
Step 3: Install and run the Upgrade check scripts
'''''''''''''''''''''''''''''''''''''''''''''''''
-After upgrading to Airflow 1.10.14, we recommend that you install the "upgrade check" scripts. These scripts will read through your ``airflow.cfg`` and all of your DAGs and will give a detailed report of all changes required before upgrading. We are testing this script diligently, and our goal is that any Airflow setup that can pass these tests will be able to upgrade to 2.0 without any issues.
+After upgrading to Airflow 1.10.15, we recommend that you install the "upgrade check" scripts. These scripts will read through your ``airflow.cfg`` and all of your DAGs and will give a detailed report of all changes required before upgrading. We are testing this script diligently, and our goal is that any Airflow setup that can pass these tests will be able to upgrade to 2.0 without any issues.
.. code-block:: bash
@@ -91,7 +91,7 @@ More details about this process are here :ref:`Upgrade Check Scripts<upgrade-che
Step 4: Import Operators from Backport Providers
''''''''''''''''''''''''''''''''''''''''''''''''
-Now that you are set up in Airflow 1.10.14 with Python a 3.6+ environment, you are ready to start porting your DAGs to Airflow 2.0 compliance!
+Now that you are set up in Airflow 1.10.15 with Python a 3.6+ environment, you are ready to start porting your DAGs to Airflow 2.0 compliance!
The most important step in this transition is also the easiest step to do in pieces. All Airflow 2.0 operators are backwards compatible with Airflow 1.10
using the backport provider packages. In your own time, you can transition to using these backport-providers
@@ -314,7 +314,7 @@ the ``rbac`` options in ``[webserver]`` in the ``airflow.cfg`` file to ``True``
In order to login to the interface, you need to create an administrator account.
-Assuming you have already installed Airflow 1.10.14, you can create a user with
+Assuming you have already installed Airflow 1.10.15, you can create a user with
Airflow 2.0 CLI command syntax ``airflow users create``.
You don't need to make changes to the configuration file as the FAB RBAC UI is
the only supported UI.
@@ -334,7 +334,7 @@ the only supported UI.
When multiple replicas of the airflow webserver are running they
need to share the same *secret_key* to access the same user session. Inject
- this via any configuration mechanism. The 1.10.14 bridge-release modifies this feature
+ this via any configuration mechanism. The 1.10.15 bridge-release modifies this feature
to use randomly generated secret keys instead of an insecure default and may break existing
deployments that rely on the default.
@@ -523,7 +523,7 @@ At this point, just follow the standard Airflow version upgrade process:
The database upgrade may take a while depending on the number of DAGs in the database and the volume of history
stored in the database for task history, xcom variables, etc.
- In our testing, we saw that performing the Airflow database upgrade from Airflow 1.10.14 to Airflow 2.0
+ In our testing, we saw that performing the Airflow database upgrade from Airflow 1.10.15 to Airflow 2.0
took between two to three minutes on an Airflow database on PostgreSQL with around 35,000 task instances and
500 DAGs.
For a faster database upgrade and for better overall performance, it is recommended that you periodically archive
diff --git a/docs/docker-stack/build-arg-ref.rst b/docs/docker-stack/build-arg-ref.rst
new file mode 100644
index 0000000..57d4da5
--- /dev/null
+++ b/docs/docker-stack/build-arg-ref.rst
@@ -0,0 +1,212 @@
+ .. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ .. http://www.apache.org/licenses/LICENSE-2.0
+
+ .. Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+Image build arguments reference
+-------------------------------
+
+The following build arguments (``--build-arg`` in docker build command) can be used for production images:
+
++------------------------------------------+------------------------------------------+------------------------------------------+
+| Build argument | Default value | Description |
++==========================================+==========================================+==========================================+
+| ``PYTHON_BASE_IMAGE`` | ``python:3.6-slim-buster`` | Base python image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``PYTHON_MAJOR_MINOR_VERSION`` | ``3.6`` | major/minor version of Python (should |
+| | | match base image). |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_VERSION`` | ``2.0.1.dev0`` | version of Airflow. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_REPO`` | ``apache/airflow`` | the repository from which PIP |
+| | | dependencies are pre-installed. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_BRANCH`` | ``master`` | the branch from which PIP dependencies |
+| | | are pre-installed initially. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_CONSTRAINTS_LOCATION`` | | If not empty, it will override the |
+| | | source of the constraints with the |
+| | | specified URL or file. Note that the |
+| | | file has to be in docker context so |
+| | | it's best to place such file in |
+| | | one of the folders included in |
+| | | ``.dockerignore`` file. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_CONSTRAINTS_REFERENCE`` | ``constraints-master`` | Reference (branch or tag) from GitHub |
+| | | where constraints file is taken from |
+| | | It can be ``constraints-master`` but |
+| | | also can be ``constraints-1-10`` for |
+| | | 1.10.* installation. In case of building |
+| | | specific version you want to point it |
+| | | to specific tag, for example |
+| | | ``constraints-1.10.15``. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``INSTALL_PROVIDERS_FROM_SOURCES`` | ``false`` | If set to ``true`` and image is built |
+| | | from sources, all provider packages are |
+| | | installed from sources rather than from |
+| | | packages. It has no effect when |
+| | | installing from PyPI or GitHub repo. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_EXTRAS`` | (see Dockerfile) | Default extras with which airflow is |
+| | | installed. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``INSTALL_FROM_PYPI`` | ``true`` | If set to true, Airflow is installed |
+| | | from PyPI. if you want to install |
+| | | Airflow from self-build package |
+| | | you can set it to false, put package in |
+| | | ``docker-context-files`` and set |
+| | | ``INSTALL_FROM_DOCKER_CONTEXT_FILES`` to |
+| | | ``true``. For this you have to also keep |
+| | | ``AIRFLOW_PRE_CACHED_PIP_PACKAGES`` flag |
+| | | set to ``false``. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_PRE_CACHED_PIP_PACKAGES`` | ``false`` | Allows to pre-cache airflow PIP packages |
+| | | from the GitHub of Apache Airflow |
+| | | This allows to optimize iterations for |
+| | | Image builds and speeds up CI builds. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``INSTALL_FROM_DOCKER_CONTEXT_FILES`` | ``false`` | If set to true, Airflow, providers and |
+| | | all dependencies are installed from |
+| | | from locally built/downloaded |
+| | | .whl and .tar.gz files placed in the |
+| | | ``docker-context-files``. In certain |
+| | | corporate environments, this is required |
+| | | to install airflow from such pre-vetted |
+| | | packages rather than from PyPI. For this |
+| | | to work, also set ``INSTALL_FROM_PYPI``. |
+| | | Note that packages starting with |
+| | | ``apache?airflow`` glob are treated |
+| | | differently than other packages. All |
+| | | ``apache?airflow`` packages are |
+| | | installed with dependencies limited by |
+| | | airflow constraints. All other packages |
+| | | are installed without dependencies |
+| | | 'as-is'. If you wish to install airflow |
+| | | via 'pip download' with all dependencies |
+| | | downloaded, you have to rename the |
+| | | apache airflow and provider packages to |
+| | | not start with ``apache?airflow`` glob. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``UPGRADE_TO_NEWER_DEPENDENCIES`` | ``false`` | If set to true, the dependencies are |
+| | | upgraded to newer versions matching |
+| | | setup.py before installation. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``CONTINUE_ON_PIP_CHECK_FAILURE`` | ``false`` | By default the image build fails if pip |
+| | | check fails for it. This is good for |
+| | | interactive building but on CI the |
+| | | image should be built regardless - we |
+| | | have a separate step to verify image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_AIRFLOW_EXTRAS`` | | Optional additional extras with which |
+| | | airflow is installed. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_PYTHON_DEPS`` | | Optional python packages to extend |
+| | | the image with some extra dependencies. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``DEV_APT_COMMAND`` | (see Dockerfile) | Dev apt command executed before dev deps |
+| | | are installed in the Build image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_DEV_APT_COMMAND`` | | Additional Dev apt command executed |
+| | | before dev dep are installed |
+| | | in the Build image. Should start with |
+| | | ``&&``. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``DEV_APT_DEPS`` | (see Dockerfile) | Dev APT dependencies installed |
+| | | in the Build image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_DEV_APT_DEPS`` | | Additional apt dev dependencies |
+| | | installed in the Build image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_DEV_APT_ENV`` | | Additional env variables defined |
+| | | when installing dev deps. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``RUNTIME_APT_COMMAND`` | (see Dockerfile) | Runtime apt command executed before deps |
+| | | are installed in the Main image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_RUNTIME_APT_COMMAND`` | | Additional Runtime apt command executed |
+| | | before runtime dep are installed |
+| | | in the Main image. Should start with |
+| | | ``&&``. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``RUNTIME_APT_DEPS`` | (see Dockerfile) | Runtime APT dependencies installed |
+| | | in the Main image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_RUNTIME_APT_DEPS`` | | Additional apt runtime dependencies |
+| | | installed in the Main image. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``ADDITIONAL_RUNTIME_APT_ENV`` | | Additional env variables defined |
+| | | when installing runtime deps. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_HOME`` | ``/opt/airflow`` | Airflow’s HOME (that’s where logs and |
+| | | SQLite databases are stored). |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_UID`` | ``50000`` | Airflow user UID. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_GID`` | ``50000`` | Airflow group GID. Note that most files |
+| | | created on behalf of airflow user belong |
+| | | to the ``root`` group (0) to keep |
+| | | OpenShift Guidelines compatibility. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_USER_HOME_DIR`` | ``/home/airflow`` | Home directory of the Airflow user. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``CASS_DRIVER_BUILD_CONCURRENCY`` | ``8`` | Number of processors to use for |
+| | | cassandra PIP install (speeds up |
+| | | installing in case cassandra extra is |
+| | | used). |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``INSTALL_MYSQL_CLIENT`` | ``true`` | Whether MySQL client should be installed |
+| | | The mysql extra is removed from extras |
+| | | if the client is not installed. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``AIRFLOW_PIP_VERSION`` | ``20.2.4`` | PIP version used. |
++------------------------------------------+------------------------------------------+------------------------------------------+
+| ``PIP_PROGRESS_BAR`` | ``on`` | Progress bar for PIP installation |
++------------------------------------------+------------------------------------------+------------------------------------------+
+
+There are build arguments that determine the installation mechanism of Apache Airflow for the
+production image. There are three types of build:
+
+* From local sources (by default for example when you use ``docker build .``)
+* You can build the image from released PyPI airflow package (used to build the official Docker image)
+* You can build the image from any version in GitHub repository(this is used mostly for system testing).
+
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+
+| Build argument | Default | What to specify |
++===================================+========================+===================================================================================+
+| ``AIRFLOW_INSTALLATION_METHOD`` | ``apache-airflow`` | Should point to the installation method of Apache Airflow. It can be |
+| | | ``apache-airflow`` for installation from packages and URL to installation from |
+| | | GitHub repository tag or branch or "." to install from sources. |
+| | | Note that installing from local sources requires appropriate values of the |
+| | | ``AIRFLOW_SOURCES_FROM`` and ``AIRFLOW_SOURCES_TO`` variables as described below. |
+| | | Only used when ``INSTALL_FROM_PYPI`` is set to ``true``. |
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+
+| ``AIRFLOW_VERSION_SPECIFICATION`` | | Optional - might be used for package installation of different Airflow version |
+| | | for example"==2.0.1". For consistency, you should also set``AIRFLOW_VERSION`` |
+| | | to the same value AIRFLOW_VERSION is resolved as label in the image created. |
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+
+| ``AIRFLOW_CONSTRAINTS_REFERENCE`` | ``constraints-master`` | Reference (branch or tag) from GitHub where constraints file is taken from. |
+| | | It can be ``constraints-master`` but also can be``constraints-1-10`` for |
+| | | 1.10.* installations. In case of building specific version |
+| | | you want to point it to specific tag, for example ``constraints-2.0.1`` |
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+
+| ``AIRFLOW_WWW`` | ``www`` | In case of Airflow 2.0 it should be "www", in case of Airflow 1.10 |
+| | | series it should be "www_rbac". |
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+
+| ``AIRFLOW_SOURCES_FROM`` | ``empty`` | Sources of Airflow. Set it to "." when you install airflow from |
+| | | local sources. |
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+
+| ``AIRFLOW_SOURCES_TO`` | ``/empty`` | Target for Airflow sources. Set to "/opt/airflow" when |
+| | | you want to install airflow from local sources. |
++-----------------------------------+------------------------+-----------------------------------------------------------------------------------+