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 <[email protected]>
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 [email protected]
-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.
