You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by po...@apache.org on 2023/02/03 05:23:39 UTC
[airflow] branch main updated: Fixup some punctuation and grammar (#29342)
This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new 70a174c47f Fixup some punctuation and grammar (#29342)
70a174c47f is described below
commit 70a174c47f14f43445d59b8249ee4f0dab4ea995
Author: Jed Cunningham <66...@users.noreply.github.com>
AuthorDate: Thu Feb 2 23:23:15 2023 -0600
Fixup some punctuation and grammar (#29342)
After noticing one punctuation mistake around "however", I figured there
must be more. So I fixed them, and some other stuff adjacent to them.
---
.../operators/cloud/dataflow.rst | 2 +-
docs/apache-airflow-providers-http/operators.rst | 6 ++---
.../howto/create-update-providers.rst | 6 ++---
docs/apache-airflow-providers/index.rst | 4 ++--
.../administration-and-deployment/lineage.rst | 2 +-
.../logging-monitoring/errors.rst | 6 ++---
.../administration-and-deployment/scheduler.rst | 8 +++----
.../security/secrets/secrets-backend/index.rst | 2 +-
.../security/webserver.rst | 3 ---
.../dynamic-task-mapping.rst | 4 ++--
docs/apache-airflow/best-practices.rst | 14 ++++++------
docs/apache-airflow/faq.rst | 2 +-
docs/apache-airflow/howto/connection.rst | 4 ++--
docs/apache-airflow/howto/set-up-database.rst | 4 ++--
.../howto/upgrading-from-1-10/index.rst | 2 +-
docs/apache-airflow/installation/dependencies.rst | 4 ++--
docs/apache-airflow/installation/index.rst | 10 ++++-----
.../installation/supported-versions.rst | 6 ++---
docs/apache-airflow/installation/upgrading.rst | 6 ++---
docs/apache-airflow/migrations-ref.rst | 4 ++--
docs/docker-stack/build.rst | 26 +++++++++++-----------
docs/docker-stack/changelog.rst | 10 ++++-----
docs/docker-stack/entrypoint.rst | 4 ++--
docs/helm-chart/production-guide.rst | 4 ++--
docs/helm-chart/quick-start.rst | 4 ++--
25 files changed, 72 insertions(+), 75 deletions(-)
diff --git a/docs/apache-airflow-providers-google/operators/cloud/dataflow.rst b/docs/apache-airflow-providers-google/operators/cloud/dataflow.rst
index 1b1f929a30..e72228ae9a 100644
--- a/docs/apache-airflow-providers-google/operators/cloud/dataflow.rst
+++ b/docs/apache-airflow-providers-google/operators/cloud/dataflow.rst
@@ -146,7 +146,7 @@ See: `Configuring PipelineOptions for execution on the Cloud Dataflow service <h
Asynchronous execution
""""""""""""""""""""""
-Dataflow batch jobs are by default asynchronous - however this is dependent on the application code (contained in the JAR
+Dataflow batch jobs are by default asynchronous; however, this is dependent on the application code (contained in the JAR
or Python file) and how it is written. In order for the Dataflow job to execute asynchronously, ensure the
pipeline objects are not being waited upon (not calling ``waitUntilFinish`` or ``wait_until_finish`` on the
``PipelineResult`` in your application code).
diff --git a/docs/apache-airflow-providers-http/operators.rst b/docs/apache-airflow-providers-http/operators.rst
index 8c67a963ca..45fa454a29 100644
--- a/docs/apache-airflow-providers-http/operators.rst
+++ b/docs/apache-airflow-providers-http/operators.rst
@@ -49,7 +49,7 @@ the response text back.
For historical reasons, configuring ``HTTPS`` connectivity via HTTP operator is, well, difficult and
counter-intuitive. The Operator defaults to ``http`` protocol and you can change the schema used by the
- operator via ``scheme`` connection attribute. However this field was originally added to connection for
+ operator via ``scheme`` connection attribute. However, this field was originally added to connection for
database type of URIs, where database schemes are set traditionally as first component of URI ``path``.
Therefore if you want to configure as ``https`` connection via URI, you need to pass ``https`` scheme
to the SimpleHttpOperator. AS stupid as it looks, your connection URI will look like this:
@@ -58,8 +58,8 @@ the response text back.
``https://your_host:443/my_endpoint`` you need to set the endpoint parameter to ``my_endpoint``.
Alternatively, if you want, you could also percent-encode the host including the ``https://`` prefix,
and as long it contains ``://`` (percent-encoded ``%3a%2f%2f``), the first component of the path will
- not be used as scheme. Your URI definition might then look like: ``http://https%3a%2f%2fyour_host:443/``
- In this case however the ``path`` will not be used at all - you still need to use ``endpoint``
+ not be used as scheme. Your URI definition might then look like ``http://https%3a%2f%2fyour_host:443/``.
+ In this case, however, the ``path`` will not be used at all - you still need to use ``endpoint``
parameter in the task if wish to make a request with specific path. As counter-intuitive as it is, this
is historically the way how the operator/hook works and it's not easy to change without breaking
backwards compatibility because there are other operators build on top of the ``SimpleHttpOperator`` that
diff --git a/docs/apache-airflow-providers/howto/create-update-providers.rst b/docs/apache-airflow-providers/howto/create-update-providers.rst
index 5231b69a68..723e70bec3 100644
--- a/docs/apache-airflow-providers/howto/create-update-providers.rst
+++ b/docs/apache-airflow-providers/howto/create-update-providers.rst
@@ -246,7 +246,7 @@ In the ``airflow/providers/<NEW_PROVIDER>/provider.yaml`` add information of you
.. note:: Defining your own connection types
- You only need to add ``connection-types`` in case you have some hooks that have customized UI behavior. However
+ You only need to add ``connection-types`` in case you have some hooks that have customized UI behavior. However,
it is only supported for Airflow 2.2.0. If your providers are also targeting Airflow below 2.2.0 you should
provide the deprecated ``hook-class-names`` array. The ``connection-types`` array allows for optimization
of importing of individual connections and while Airflow 2.2.0 is able to handle both definition, the
@@ -272,10 +272,10 @@ Optional provider features
This feature is available in Airflow 2.3+.
Some providers might provide optional features, which are only available when some packages or libraries
-are installed. Such features will typically result in ``ImportErrors`` however those import errors
+are installed. Such features will typically result in ``ImportErrors``; however, those import errors
should be silently ignored rather than pollute the logs of Airflow with false warnings. False warnings
are a very bad pattern, as they tend to turn into blind spots, so avoiding false warnings is encouraged.
-However until Airflow 2.3, Airflow had no mechanism to selectively ignore "known" ImportErrors. So
+However, until Airflow 2.3, Airflow had no mechanism to selectively ignore "known" ImportErrors. So
Airflow 2.1 and 2.2 silently ignored all ImportErrors coming from providers with actually lead to
ignoring even important import errors - without giving the clue to Airflow users that there is something
missing in provider dependencies.
diff --git a/docs/apache-airflow-providers/index.rst b/docs/apache-airflow-providers/index.rst
index ddb5652964..9ca01c4ba0 100644
--- a/docs/apache-airflow-providers/index.rst
+++ b/docs/apache-airflow-providers/index.rst
@@ -83,8 +83,8 @@ Logging
'''''''
The providers can add additional task logging capabilities. By default ``Apache Airflow`` saves logs for
-tasks locally and make them available to Airflow UI via internal http server, however via providers
-you can add extra logging capabilities, where Airflow Logs can be written to a remote service and
+tasks locally and make them available to Airflow UI via internal http server. However, providers
+can add extra logging capabilities, where Airflow Logs can be written to a remote service and
retrieved from those services.
You can see all task loggers available via community-managed providers in
diff --git a/docs/apache-airflow/administration-and-deployment/lineage.rst b/docs/apache-airflow/administration-and-deployment/lineage.rst
index d717f59e24..7b967d3f10 100644
--- a/docs/apache-airflow/administration-and-deployment/lineage.rst
+++ b/docs/apache-airflow/administration-and-deployment/lineage.rst
@@ -63,7 +63,7 @@ works.
Inlets can be a (list of) upstream task ids or statically defined as an attr annotated object
as is, for example, the ``File`` object. Outlets can only be attr annotated object. Both are rendered
-at run time. However the outlets of a task in case they are inlets to another task will not be re-rendered
+at run time. However, the outlets of a task in case they are inlets to another task will not be re-rendered
for the downstream task.
.. note:: Operators can add inlets and outlets automatically if the operator supports it.
diff --git a/docs/apache-airflow/administration-and-deployment/logging-monitoring/errors.rst b/docs/apache-airflow/administration-and-deployment/logging-monitoring/errors.rst
index 1541a737e9..33e0a2d26d 100644
--- a/docs/apache-airflow/administration-and-deployment/logging-monitoring/errors.rst
+++ b/docs/apache-airflow/administration-and-deployment/logging-monitoring/errors.rst
@@ -95,9 +95,9 @@ environment variables are passed but also all existing environment variables are
``SUBPROCESS_`` prefix added. This happens also for all other subprocesses.
This behaviour can be disabled by setting ``default_integrations`` sentry configuration parameter to
-``False`` which disables ``StdlibIntegration``. This however also disables other default integrations
-and you need to enable them manually if you want to get them enabled,
-see `Sentry Default Integrations <https://docs.sentry.io/platforms/python/guides/wsgi/configuration/integrations/default-integrations/>`_
+``False`` which disables ``StdlibIntegration``. However, this also disables other default integrations,
+so you need to enable them manually if you want them to remain enabled
+(see `Sentry Default Integrations <https://docs.sentry.io/platforms/python/guides/wsgi/configuration/integrations/default-integrations/>`_).
.. code-block:: ini
diff --git a/docs/apache-airflow/administration-and-deployment/scheduler.rst b/docs/apache-airflow/administration-and-deployment/scheduler.rst
index a1af03e586..3c2eee3b5d 100644
--- a/docs/apache-airflow/administration-and-deployment/scheduler.rst
+++ b/docs/apache-airflow/administration-and-deployment/scheduler.rst
@@ -111,7 +111,7 @@ outline of the scheduling loop is:
- Select schedulable TaskInstances, and whilst respecting Pool limits and other concurrency limits, enqueue
them for execution
-This does however place some requirements on the Database.
+This does, however, place some requirements on the Database.
.. _scheduler:ha:db_requirements:
@@ -274,7 +274,7 @@ There are several areas of resource usage that you should pay attention to:
which dramatically decreases performance. Note that Airflow Scheduler in versions prior to ``2.1.4``
generated a lot of ``Page Cache`` memory used by log files (when the log files were not removed).
This was generally harmless, as the memory is just cache and could be reclaimed at any time by the system,
- however in version ``2.1.4`` and beyond, writing logs will not generate excessive ``Page Cache`` memory.
+ however, in version ``2.1.4`` and beyond, writing logs will not generate excessive ``Page Cache`` memory.
Regardless - make sure when you look at memory usage, pay attention to the kind of memory you are observing.
Usually you should look at ``working memory``(names might vary depending on your deployment) rather
than ``total memory used``.
@@ -314,8 +314,8 @@ Scheduler Configuration options
"""""""""""""""""""""""""""""""
The following config settings can be used to control aspects of the Scheduler.
-However you can also look at other non-performance-related scheduler configuration parameters available at
-:doc:`../configurations-ref` in ``[scheduler]`` section.
+However, you can also look at other non-performance-related scheduler configuration parameters available at
+:doc:`../configurations-ref` in the ``[scheduler]`` section.
- :ref:`config:scheduler__max_dagruns_to_create_per_loop`
diff --git a/docs/apache-airflow/administration-and-deployment/security/secrets/secrets-backend/index.rst b/docs/apache-airflow/administration-and-deployment/security/secrets/secrets-backend/index.rst
index 9d0f44ba44..06b820a373 100644
--- a/docs/apache-airflow/administration-and-deployment/security/secrets/secrets-backend/index.rst
+++ b/docs/apache-airflow/administration-and-deployment/security/secrets/secrets-backend/index.rst
@@ -114,6 +114,6 @@ Adapt to non-Airflow compatible secret formats for connections
The default implementation of Secret backend requires use of an Airflow-specific format of storing
secrets for connections. Currently most community provided implementations require the connections to
be stored as JSON or the Airflow Connection URI format (see
-:doc:`apache-airflow-providers:core-extensions/secrets-backends`). However some organizations may need to store the credentials (passwords/tokens etc) in some other way, for example if the same credentials store needs to be used for multiple data platforms, or if you are using a service with a built-in mechanism of rotating the credentials that does not work with the Airflow-specific format.
+:doc:`apache-airflow-providers:core-extensions/secrets-backends`). However, some organizations may need to store the credentials (passwords/tokens etc) in some other way. For example, if the same credentials store needs to be used for multiple data platforms, or if you are using a service with a built-in mechanism of rotating the credentials that does not work with the Airflow-specific format.
In this case you will need to roll your own secret backend as described in the previous chapter,
possibly extending an existing secrets backend and adapting it to the scheme used by your organization.
diff --git a/docs/apache-airflow/administration-and-deployment/security/webserver.rst b/docs/apache-airflow/administration-and-deployment/security/webserver.rst
index f08b84d32b..7e3cf3b6df 100644
--- a/docs/apache-airflow/administration-and-deployment/security/webserver.rst
+++ b/docs/apache-airflow/administration-and-deployment/security/webserver.rst
@@ -66,9 +66,6 @@ following CLI commands to create an account:
--role Admin \
--email spiderman@superhero.org
-It is however possible to switch on authentication by either using one of the supplied
-backends or creating your own.
-
To deactivate the authentication and allow users to be identified as Anonymous, the following entry
in ``$AIRFLOW_HOME/webserver_config.py`` needs to be set with the desired role that the Anonymous
user will have by default:
diff --git a/docs/apache-airflow/authoring-and-scheduling/dynamic-task-mapping.rst b/docs/apache-airflow/authoring-and-scheduling/dynamic-task-mapping.rst
index a8d0176263..f6c95660ab 100644
--- a/docs/apache-airflow/authoring-and-scheduling/dynamic-task-mapping.rst
+++ b/docs/apache-airflow/authoring-and-scheduling/dynamic-task-mapping.rst
@@ -169,7 +169,7 @@ As well as a single parameter it is possible to pass multiple parameters to expa
# add(x=8, y=5)
# add(x=8, y=10)
-This would result in the add task being called 6 times. Please note however that the order of expansion is not guaranteed.
+This would result in the add task being called 6 times. Please note, however, that the order of expansion is not guaranteed.
Mapping with non-TaskFlow operators
===================================
@@ -522,7 +522,7 @@ There are two limits that you can place on a task:
If you wish to not have a large mapped task consume all available runner slots you can use the ``max_active_tis_per_dag`` setting on the task to restrict how many can be running at the same time.
- Note however that this applies to all copies of that task against all active DagRuns, not just to this one specific DagRun.
+ Note, however, that this applies to all copies of that task against all active DagRuns, not just to this one specific DagRun.
.. code-block:: python
diff --git a/docs/apache-airflow/best-practices.rst b/docs/apache-airflow/best-practices.rst
index 65a3d29fa0..db9189a155 100644
--- a/docs/apache-airflow/best-practices.rst
+++ b/docs/apache-airflow/best-practices.rst
@@ -404,8 +404,8 @@ your DAG "less complex" - since this is a Python code, it's the DAG writer who c
their code.
There are no "metrics" for DAG complexity, especially, there are no metrics that can tell you
-whether your DAG is "simple enough". However - as with any Python code you can definitely tell that
-your code is "simpler" or "faster" when you optimize it, the same can be said about DAG code. If you
+whether your DAG is "simple enough". However, as with any Python code, you can definitely tell that
+your DAG code is "simpler" or "faster" when it is optimized. If you
want to optimize your DAGs there are the following actions you can take:
* Make your DAG load faster. This is a single improvement advice that might be implemented in various ways
@@ -712,9 +712,9 @@ and the dependencies basically conflict between those tasks.
If you are using pre-defined Airflow Operators to talk to external services, there is not much choice, but usually those
operators will have dependencies that are not conflicting with basic Airflow dependencies. Airflow uses constraints mechanism
which means that you have a "fixed" set of dependencies that the community guarantees that Airflow can be installed with
-(including all community providers) without triggering conflicts. However you can upgrade the providers
-independently and their constraints do not limit you so the chance of a conflicting dependency is lower (you still have
-to test those dependencies). Therefore when you are using pre-defined operators, chance is that you will have
+(including all community providers) without triggering conflicts. However, you can upgrade the providers
+independently and their constraints do not limit you, so the chance of a conflicting dependency is lower (you still have
+to test those dependencies). Therefore, when you are using pre-defined operators, chance is that you will have
little, to no problems with conflicting dependencies.
However, when you are approaching Airflow in a more "modern way", where you use TaskFlow Api and most of
@@ -799,7 +799,7 @@ A bit more involved but with significantly less overhead, security, stability pr
:class:`airflow.operators.python.ExternalPythonOperator``. In the modern
TaskFlow approach described in :doc:`/tutorial/taskflow`. this also can be done with decorating
your callable with ``@task.external_python`` decorator (recommended way of using the operator).
-It requires however that you have a pre-existing, immutable Python environment, that is prepared upfront.
+It requires, however, that you have a pre-existing, immutable Python environment, that is prepared upfront.
Unlike in :class:`airflow.operators.python.PythonVirtualenvOperator` you cannot add new dependencies
to such pre-existing environment. All dependencies you need should be added upfront in your environment
and available in all the workers in case your Airflow runs in a distributed environment.
@@ -928,7 +928,7 @@ Using multiple Docker Images and Celery Queues
There is a possibility (though it requires a deep knowledge of Airflow deployment) to run Airflow tasks
using multiple, independent Docker images. This can be achieved via allocating different tasks to different
-Queues and configuring your Celery workers to use different images for different Queues. This however
+Queues and configuring your Celery workers to use different images for different Queues. This, however,
(at least currently) requires a lot of manual deployment configuration and intrinsic knowledge of how
Airflow, Celery and Kubernetes works. Also it introduces quite some overhead for running the tasks - there
are less chances for resource reuse and it's much more difficult to fine-tune such a deployment for
diff --git a/docs/apache-airflow/faq.rst b/docs/apache-airflow/faq.rst
index 684b6a0bdd..825206ad5b 100644
--- a/docs/apache-airflow/faq.rst
+++ b/docs/apache-airflow/faq.rst
@@ -111,7 +111,7 @@ How to reduce DAG scheduling latency / task delay?
--------------------------------------------------
Airflow 2.0 has low DAG scheduling latency out of the box (particularly when compared with Airflow 1.10.x),
-however if you need more throughput you can :ref:`start multiple schedulers<scheduler:ha>`.
+however, if you need more throughput you can :ref:`start multiple schedulers<scheduler:ha>`.
How do I trigger tasks based on another task's failure?
diff --git a/docs/apache-airflow/howto/connection.rst b/docs/apache-airflow/howto/connection.rst
index d1ca89e09a..9792d6faaa 100644
--- a/docs/apache-airflow/howto/connection.rst
+++ b/docs/apache-airflow/howto/connection.rst
@@ -290,8 +290,8 @@ and :py:class:`~airflow.providers.asana.hooks.jdbc.AsanaHook` both make use of t
.. note:: Deprecated ``hook-class-names``
Prior to Airflow 2.2.0, the connections in providers have been exposed via ``hook-class-names`` array
- in provider's meta-data, this however has proven to be not well optimized for using individual hooks
- in workers and the ``hook-class-names`` array is now replaced by ``connection-types`` array. Until
+ in provider's meta-data. However, this has proven to be inefficient when using individual hooks
+ in workers, and the ``hook-class-names`` array is now replaced by the ``connection-types`` array. Until
provider supports Airflow below 2.2.0, both ``connection-types`` and ``hook-class-names`` should be
present. Automated checks during CI build will verify consistency of those two arrays.
diff --git a/docs/apache-airflow/howto/set-up-database.rst b/docs/apache-airflow/howto/set-up-database.rst
index edbf0b7902..70de5f5339 100644
--- a/docs/apache-airflow/howto/set-up-database.rst
+++ b/docs/apache-airflow/howto/set-up-database.rst
@@ -295,14 +295,14 @@ We recommend using the ``mysqlclient`` driver and specifying it in your SqlAlche
mysql+mysqldb://<user>:<password>@<host>[:<port>]/<dbname>
-But we also support the ``mysql-connector-python`` driver, which lets you connect through SSL
+We also support the ``mysql-connector-python`` driver, which lets you connect through SSL
without any cert options provided.
.. code-block:: text
mysql+mysqlconnector://<user>:<password>@<host>[:<port>]/<dbname>
-However if you want to use other drivers visit the `MySQL Dialect <https://docs.sqlalchemy.org/en/13/dialects/mysql.html>`__ in SQLAlchemy documentation for more information regarding download
+If you want to use other drivers visit the `MySQL Dialect <https://docs.sqlalchemy.org/en/13/dialects/mysql.html>`__ in SQLAlchemy documentation for more information regarding download
and setup of the SqlAlchemy connection.
In addition, you also should pay particular attention to MySQL's encoding. Although the ``utf8mb4`` character set is more and more popular for MySQL (actually, ``utf8mb4`` becomes default character set in MySQL8.0), using the ``utf8mb4`` encoding requires additional setting in Airflow 2+ (See more details in `#7570 <https://github.com/apache/airflow/pull/7570>`__.). If you use ``utf8mb4`` as character set, you should also set ``sql_engine_collation_for_ids=utf8mb3_bin``.
diff --git a/docs/apache-airflow/howto/upgrading-from-1-10/index.rst b/docs/apache-airflow/howto/upgrading-from-1-10/index.rst
index 14b0b33842..c599f357f7 100644
--- a/docs/apache-airflow/howto/upgrading-from-1-10/index.rst
+++ b/docs/apache-airflow/howto/upgrading-from-1-10/index.rst
@@ -879,7 +879,7 @@ Migration Guide from Experimental API to Stable API v1
In Airflow 2.0, we added the new REST API. Experimental API still works, but support may be dropped in the future.
-The experimental API however does not require authentication, so it is disabled by default. You need to explicitly enable the experimental API if you want to use it.
+The experimental API, however, does not require authentication, so it is disabled by default. You need to explicitly enable the experimental API if you want to use it.
If your application is still using the experimental API, you should **seriously** consider migrating to the stable API.
The stable API exposes many endpoints available through the webserver. Here are the
diff --git a/docs/apache-airflow/installation/dependencies.rst b/docs/apache-airflow/installation/dependencies.rst
index 912cb4ef3e..94eed45609 100644
--- a/docs/apache-airflow/installation/dependencies.rst
+++ b/docs/apache-airflow/installation/dependencies.rst
@@ -30,7 +30,7 @@ yum package, or whatever equivalent applies on the distribution you are using.
Most of the extra dependencies are linked to a corresponding provider package. For example "amazon" extra
has a corresponding ``apache-airflow-providers-amazon`` provider package to be installed. When you install
Airflow with such extras, the necessary provider packages are installed automatically (latest versions from
-PyPI for those packages). However you can freely upgrade and install provider packages independently from
+PyPI for those packages). However, you can freely upgrade and install provider packages independently from
the main Airflow installation.
For the list of the extras and what they enable, see: :doc:`/extra-packages-ref`.
@@ -60,7 +60,7 @@ packages, but not all optional features of Apache Airflow have corresponding pro
We are using the ``extras`` setuptools features to also install provider packages.
Most of the extras are also linked (same name) with provider packages - for example adding ``[google]``
-extra also adds ``apache-airflow-providers-google`` as dependency. However there are some extras that do
+extra also adds ``apache-airflow-providers-google`` as dependency. However, there are some extras that do
not install providers (examples ``github_enterprise``, ``kerberos``, ``async`` - they add some extra
dependencies which are needed for those ``extra`` features of Airflow mentioned. The three examples
above add respectively GitHub Enterprise OAuth authentication, Kerberos integration or
diff --git a/docs/apache-airflow/installation/index.rst b/docs/apache-airflow/installation/index.rst
index 7fd4381001..d30c65868e 100644
--- a/docs/apache-airflow/installation/index.rst
+++ b/docs/apache-airflow/installation/index.rst
@@ -132,8 +132,8 @@ More details: :doc:`/installation/installing-from-pypi`
diagnose and solve.
* You have :doc:`/start` where you can see an example of Quick Start with running Airflow
locally which you can use to start Airflow quickly for local testing and development.
- However this is just an inspiration. Do not expect this docker-compose is ready for production installation,
- you need to build your own production-ready deployment in this approach.
+ However, this is just for inspiration. Do not expect this docker-compose is ready for production installation,
+ you need to build your own production-ready deployment if you follow this approach.
**Where to ask for help**
@@ -174,7 +174,7 @@ and official constraint files- same that are used for installing Airflow from Py
* You are responsible to manage your own customizations and extensions for your custom dependencies.
With the Official Airflow Docker Images, upgrades of Airflow and Airflow Providers which
are part of the reference image are handled by the community - you need to make sure to pick up
- those changes when released by upgrading the base image. However you are responsible in creating a
+ those changes when released by upgrading the base image. However, you are responsible in creating a
pipeline of building your own custom images with your own added dependencies and Providers and need to
repeat the customization step and building your own image when new version of Airflow image is released.
* You should choose the right deployment mechanism. There a number of available options of
@@ -186,7 +186,7 @@ and official constraint files- same that are used for installing Airflow from Py
* You have instructions: :doc:`docker-stack:build` on how to build and customize your image.
* You have :doc:`/howto/docker-compose/index` where you can see an example of Quick Start which
- you can use to start Airflow quickly for local testing and development. However this is just an inspiration.
+ you can use to start Airflow quickly for local testing and development. However, this is just for inspiration.
Do not expect to use this ``docker-compose.yml`` file for production installation, you need to get familiar
with Docker Compose and its capabilities and build your own production-ready deployment with it if
you choose Docker Compose for your deployment.
@@ -235,7 +235,7 @@ More details: :doc:`helm-chart:index`
* You are responsible to manage your own customizations and extensions for your custom dependencies.
With the Official Airflow Docker Images, upgrades of Airflow and Airflow Providers which
are part of the reference image are handled by the community - you need to make sure to pick up
- those changes when released by upgrading the base image. However you are responsible in creating a
+ those changes when released by upgrading the base image. However, you are responsible in creating a
pipeline of building your own custom images with your own added dependencies and Providers and need to
repeat the customization step and building your own image when new version of Airflow image is released.
diff --git a/docs/apache-airflow/installation/supported-versions.rst b/docs/apache-airflow/installation/supported-versions.rst
index 38ace709db..65de7c2523 100644
--- a/docs/apache-airflow/installation/supported-versions.rst
+++ b/docs/apache-airflow/installation/supported-versions.rst
@@ -60,9 +60,9 @@ They are based on the official release schedule of Python and Kubernetes, nicely
2. The "oldest" supported version of Python/Kubernetes is the default one. "Default" is only meaningful
in terms of "smoke tests" in CI PRs which are run using this default version and default reference
- image available in DockerHub. Currently ``apache/airflow:latest`` and ``apache/airflow:2.0.2`` images
- are both Python 3.6 images, however the first MINOR/MAJOR release of Airflow release after 23.12.2021 will
- become Python 3.7 images.
+ image available in DockerHub. Currently the ``apache/airflow:latest`` and ``apache/airflow:2.5.1`` images
+ are Python 3.7 images, however, in the first MINOR/MAJOR release of Airflow released after 27.06.2023, they will
+ become Python 3.8 images.
3. We support a new version of Python/Kubernetes in main after they are officially released, as soon as we
make them work in our CI pipeline (which might not be immediate due to dependencies catching up with
diff --git a/docs/apache-airflow/installation/upgrading.rst b/docs/apache-airflow/installation/upgrading.rst
index cb596cef42..472151719e 100644
--- a/docs/apache-airflow/installation/upgrading.rst
+++ b/docs/apache-airflow/installation/upgrading.rst
@@ -81,7 +81,7 @@ The next chapter describes how to fix the problem manually.
Why you might get the error? The recommended character set/collation for MySQL 8 database is
-``utf8mb4`` and ``utf8mb4_bin`` respectively. However this has been changing in different versions of
+``utf8mb4`` and ``utf8mb4_bin`` respectively. However, this has been changing in different versions of
MySQL and you could have custom created database with a different character set. If your database
was created with an old version of Airflow or MySQL, the encoding could have been wrong when the database
was created or broken during migration.
@@ -208,7 +208,7 @@ Airflow version.
Post-upgrade warnings
.....................
-Typically you just need to successfully run ``airflow db upgrade`` command and this is all. However in
+Typically you just need to successfully run ``airflow db upgrade`` command and this is all. However, in
some cases, the migration might find some old, stale and probably wrong data in your database and moves it
aside to a separate table. In this case you might get warning in your webserver UI about the data found.
@@ -222,7 +222,7 @@ Typical message that you might see:
When you see such message, it means that some of your data was corrupted and you should inspect it
to determine whether you would like to keep or delete some of that data. Most likely the data was corrupted
and left-over from some bugs and can be safely deleted - because this data would not be anyhow visible
-and useful in Airflow. However if you have particular need for auditing or historical reasons you might
+and useful in Airflow. However, if you have particular need for auditing or historical reasons you might
choose to store it somewhere. Unless you have specific reasons to keep the data most likely deleting it
is your best option.
diff --git a/docs/apache-airflow/migrations-ref.rst b/docs/apache-airflow/migrations-ref.rst
index 62a106a575..08365cd250 100644
--- a/docs/apache-airflow/migrations-ref.rst
+++ b/docs/apache-airflow/migrations-ref.rst
@@ -27,8 +27,8 @@ Here's the list of all the Database Migrations that are executed via when you ru
"DB conscious" users might perform an analysis on the migrations and draw conclusions about the impact
of the migrations on their Airflow database. Those users might also want to take a look at the
:doc:`database-erd-ref` document to understand how the internal DB of Airflow structure looks like.
- However you should be aware that the structure is internal and you should not access the DB directly
- to retrieve or modify any data - you should use :doc:`stable-rest-api-ref` to do that instead.
+ However, you should be aware that the structure is internal and you should not access the DB directly
+ to retrieve or modify any data - you should use the :doc:`REST API <stable-rest-api-ref>` to do that instead.
diff --git a/docs/docker-stack/build.rst b/docs/docker-stack/build.rst
index ea6ae91db5..0020697cdb 100644
--- a/docs/docker-stack/build.rst
+++ b/docs/docker-stack/build.rst
@@ -186,7 +186,7 @@ In the simplest case building your image consists of those steps:
docker build . -f Dockerfile --pull --tag my-image:0.0.1
-3) [Optional] Test the image. Airflow contains tool that allows you to test the image. This step however,
+3) [Optional] Test the image. Airflow contains tool that allows you to test the image. This step, however,
requires locally checked out or extracted Airflow sources. If you happen to have the sources you can
test the image by running this command (in airflow root folder). The output will tell you if the image
is "good-to-go".
@@ -299,9 +299,9 @@ You should be aware, about a few things:
* If your apt, or PyPI dependencies require some of the ``build-essential`` or other packages that need
to compile your python dependencies, then your best choice is to follow the "Customize the image" route,
- because you can build a highly-optimized (for size) image this way. However it requires you to use
+ because you can build a highly-optimized (for size) image this way. However, it requires you to use
the Dockerfile that is released as part of Apache Airflow sources (also available at
- `Dockerfile <https://github.com/apache/airflow/blob/main/Dockerfile>`_)
+ `Dockerfile <https://github.com/apache/airflow/blob/main/Dockerfile>`_).
* You can also embed your dags in the image by simply adding them with COPY directive of Airflow.
The DAGs in production image are in ``/opt/airflow/dags`` folder.
@@ -449,7 +449,7 @@ Customizing the image
.. note::
You can usually use the latest ``Dockerfile`` released by Airflow to build previous Airflow versions.
- Note however, that there are slight changes in the Dockerfile and entrypoint scripts that can make it
+ Note, however, that there are slight changes in the Dockerfile and entrypoint scripts that can make it
behave slightly differently, depending which Dockerfile version you used. Details of what has changed
in each of the released versions of Docker image can be found in the :doc:`Changelog <changelog>`.
@@ -487,7 +487,7 @@ The disadvantage it that building the image takes longer and it requires you to
the Dockerfile that is released as part of Apache Airflow sources.
The disadvantage is that the pattern of building Docker images with ``--build-arg`` is less familiar
-to developers of such images. However it is quite well-known to "power-users". That's why the
+to developers of such images. However, it is quite well-known to "power-users". That's why the
customizing flow is better suited for those users who have more familiarity and have more custom
requirements.
@@ -525,7 +525,7 @@ that it can be predictably installed, even if some new versions of Airflow depen
released (or even dependencies of our dependencies!). The docker image and accompanying scripts
usually determine automatically the right versions of constraints to be used based on the Airflow
version installed and Python version. For example 2.0.2 version of Airflow installed from PyPI
-uses constraints from ``constraints-2.0.2`` tag). However in some cases - when installing airflow from
+uses constraints from ``constraints-2.0.2`` tag). However, in some cases - when installing airflow from
GitHub for example - you have to manually specify the version of constraints used, otherwise
it will default to the latest version of the constraints which might not be compatible with the
version of Airflow you use.
@@ -539,7 +539,7 @@ You can read more about constraints in :doc:`apache-airflow:installation/install
Note that if you place ``requirements.txt`` in the ``docker-context-files`` folder, it will be
used to install all requirements declared there. It is recommended that the file
contains specified version of dependencies to add with ``==`` version specifier, to achieve
-stable set of requirements, independent if someone releases a newer version. However you have
+stable set of requirements, independent if someone releases a newer version. However, you have
to make sure to update those requirements and rebuild the images to account for latest security fixes.
.. _using-docker-context-files:
@@ -584,7 +584,7 @@ You can use ``docker-context-files`` for the following purposes:
.. note::
You can also pass ``--build-arg DOCKER_CONTEXT_FILES=.`` if you want to place your ``requirements.txt``
- in main directory without creating a dedicated folder, however this is a good practice to keep any files
+ in the main directory without creating a dedicated folder. However, it is a good practice to keep any files
that you copy to the image context in a sub-folder. This makes it easier to separate things that
are used on the host from those that are passed in Docker context. Of course, by default when you run
``docker build .`` the whole folder is available as "Docker build context" and sent to the docker
@@ -826,8 +826,8 @@ where you can build the image using the packages downloaded by passing those bui
Note, that the solution we have for installing python packages from local packages, only solves the problem
of "air-gaped" python installation. The Docker image also downloads ``apt`` dependencies and ``node-modules``.
-Those types of dependencies are however more likely to be available in your "air-gaped" system via transparent
-proxies and it should automatically reach out to your private registries, however in the future the
+Those types of dependencies are more likely to be available in your "air-gaped" system via transparent
+proxies and it should automatically reach out to your private registries. However, in the future the
solution might be applied to both of those installation steps.
You can also use techniques described in the previous chapter to make ``docker build`` use your private
@@ -845,11 +845,11 @@ Modifying the Dockerfile
........................
The build arg approach is a convenience method if you do not want to manually modify the ``Dockerfile``.
-Our approach is flexible enough, to be able to accommodate most requirements and
+Our approach is flexible enough to be able to accommodate most requirements and
customizations out-of-the-box. When you use it, you do not need to worry about adapting the image every
-time new version of Airflow is released. However sometimes it is not enough if you have very
+time a new version of Airflow is released. However, sometimes it is not enough if you have very
specific needs and want to build a very custom image. In such case you can simply modify the
-``Dockerfile`` manually as you see fit and store it in your forked repository. However you will have to
+``Dockerfile`` manually as you see fit and store it in your forked repository. However, you will have to
make sure to rebase your changes whenever new version of Airflow is released, because we might modify
the approach of our Dockerfile builds in the future and you might need to resolve conflicts
and rebase your changes.
diff --git a/docs/docker-stack/changelog.rst b/docs/docker-stack/changelog.rst
index 412d5b6137..b99930397b 100644
--- a/docs/docker-stack/changelog.rst
+++ b/docs/docker-stack/changelog.rst
@@ -29,10 +29,10 @@ the Airflow team.
:note: The Changelog below concerns only the convenience production images released at
`Airflow DockerHub <https://hub.docker.com/r/apache/airflow>`_ . The images that are released
- there, are usually built using the ``Dockerfile`` released together with Airflow. However You are
+ there are usually built using the ``Dockerfile`` released together with Airflow. However, you are
free to take latest released ``Dockerfile`` from Airflow and use it to build an image for
- any Airflow version from the ``Airflow 2`` line. There is no guarantee that it works, but if it does,
- then you can use latest features from that image to build the previous Airflow versions.
+ any Airflow version from the ``Airflow 2`` line. There is no guarantee that it will work, but if it does,
+ then you can use latest features from that image to build images for previous Airflow versions.
Changes after publishing the images
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -88,8 +88,8 @@ Airflow 2.3
* 2.3.0
* Airflow 2.3 ``Dockerfile`` is now better optimized for caching and "standalone" which means that you
- can copy **just** the ``Dockerfile`` to any folder and start building custom images. This
- however requires `Buildkit <https://docs.docker.com/develop/develop-images/build_enhancements/>`_
+ can copy **just** the ``Dockerfile`` to any folder and start building custom images. This,
+ however, requires `Buildkit <https://docs.docker.com/develop/develop-images/build_enhancements/>`_
to build the image because we started using features that are only available in ``Buildkit``.
This can be done by setting ``DOCKER_BUILDKIT=1`` as an environment variable
or by installing `the buildx plugin <https://docs.docker.com/buildx/working-with-buildx/>`_
diff --git a/docs/docker-stack/entrypoint.rst b/docs/docker-stack/entrypoint.rst
index a404426d6e..83cf56fdc9 100644
--- a/docs/docker-stack/entrypoint.rst
+++ b/docs/docker-stack/entrypoint.rst
@@ -75,7 +75,7 @@ the user have also "group write" access for group ``0`` - they will be writable
folder will have a "group write" access and ``GID=0``, so that execution with another, arbitrary user
will still continue to work, even if such directory is mounted by another arbitrary user later.
-The ``umask`` setting however only works for runtime of the container - it is not used during building of
+The ``umask`` setting, however, only works for runtime of the container - it is not used during building of
the image. If you would like to extend the image and add your own packages, you should remember to add
``umask 0002`` in front of your docker command - this way the directories created by any installation
that need group access will also be writable for the group. This can be done for example this way:
@@ -199,7 +199,7 @@ Execute custom code before the Airflow entrypoint
If you want to execute some custom code before Airflow's entrypoint you can by using
a custom script and calling Airflow's entrypoint as the
-last ``exec`` instruction in your custom one. However you have to remember to use ``dumb-init`` in the same
+last ``exec`` instruction in your custom one. However, you have to remember to use ``dumb-init`` in the same
way as it is used with Airflow's entrypoint, otherwise you might have problems with proper signal
propagation (See the next chapter).
diff --git a/docs/helm-chart/production-guide.rst b/docs/helm-chart/production-guide.rst
index dc5379466e..57c0a803ac 100644
--- a/docs/helm-chart/production-guide.rst
+++ b/docs/helm-chart/production-guide.rst
@@ -209,7 +209,7 @@ They match, right? Good. Now, add the public key to your values. It'll look some
Accessing the Airflow UI
------------------------
-How you access the Airflow UI will depend on your environment, however the chart does support various options:
+How you access the Airflow UI will depend on your environment; however, the chart does support various options:
Ingress
^^^^^^^
@@ -301,7 +301,7 @@ exhaustive `Celery documentation on the topic <http://docs.celeryproject.org/en/
Security Context Constraints
-----------------------------
-A ``Security Context Constraint`` (SCC) is a OpenShift construct that works as a RBAC rule however it targets Pods instead of users.
+A ``Security Context Constraint`` (SCC) is a OpenShift construct that works as a RBAC rule; however, it targets Pods instead of users.
When defining a SCC, one can control actions and resources a POD can perform or access during startup and runtime.
The SCCs are split into different levels or categories with the ``restricted`` SCC being the default one assigned to Pods.
diff --git a/docs/helm-chart/quick-start.rst b/docs/helm-chart/quick-start.rst
index 1191121a85..009c6e0d9d 100644
--- a/docs/helm-chart/quick-start.rst
+++ b/docs/helm-chart/quick-start.rst
@@ -88,8 +88,8 @@ Extending Airflow Image
-----------------------
The Apache Airflow community, releases Docker Images which are ``reference images`` for Apache Airflow.
-However when you try it out you want to add your own DAGs, custom dependencies,
-packages or even custom providers.
+However, when you try it out you want to add your own DAGs, custom dependencies,
+packages, or even custom providers.
The best way to achieve it, is to build your own, custom image.