You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by je...@apache.org on 2022/04/27 01:04:32 UTC
[airflow] branch v2-3-test updated: fixup release notes
This is an automated email from the ASF dual-hosted git repository.
jedcunningham pushed a commit to branch v2-3-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v2-3-test by this push:
new e1713e0d66 fixup release notes
e1713e0d66 is described below
commit e1713e0d6605b6996491fb607eda403c148977a0
Author: Jed Cunningham <je...@apache.org>
AuthorDate: Tue Apr 26 19:04:05 2022 -0600
fixup release notes
---
RELEASE_NOTES.rst | 222 ++++++++++++++++++++++-----------------------
docs/spelling_wordlist.txt | 10 ++
2 files changed, 121 insertions(+), 111 deletions(-)
diff --git a/RELEASE_NOTES.rst b/RELEASE_NOTES.rst
index db2ff34097..cb02280c42 100644
--- a/RELEASE_NOTES.rst
+++ b/RELEASE_NOTES.rst
@@ -37,205 +37,205 @@ Continuing the effort to bind TaskInstance to a DagRun, XCom entries are now als
Task log templates are now read from the metadata database instead of ``airflow.cfg`` (#20165)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- Previously, a task’s log is dynamically rendered from the ``[core] log_filename_template`` and ``[elasticsearch] log_id_template`` config values at runtime. This resulted in unfortunate characteristics, e.g. it is impractical to modify the config value after an Airflow instance is running for a while, since all existing task logs have be saved under the previous format and cannot be found with the new config value.
+Previously, a task’s log is dynamically rendered from the ``[core] log_filename_template`` and ``[elasticsearch] log_id_template`` config values at runtime. This resulted in unfortunate characteristics, e.g. it is impractical to modify the config value after an Airflow instance is running for a while, since all existing task logs have be saved under the previous format and cannot be found with the new config value.
- A new ``log_template`` table is introduced to solve this problem. This table is synchronised with the aforementioned config values every time Airflow starts, and a new field ``log_template_id`` is added to every DAG run to point to the format used by tasks (``NULL`` indicates the first ever entry for compatibility).
+A new ``log_template`` table is introduced to solve this problem. This table is synchronized with the aforementioned config values every time Airflow starts, and a new field ``log_template_id`` is added to every DAG run to point to the format used by tasks (``NULL`` indicates the first ever entry for compatibility).
Minimum kubernetes version bumped from ``3.0.0`` to ``21.7.0`` (#20759)
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- No change in behavior is expected. This was necessary in order to take advantage of a `bugfix <https://github.com/kubernetes-client/python-base/commit/70b78cd8488068c014b6d762a0c8d358273865b4>`_ concerning refreshing of Kubernetes API tokens with EKS, which enabled the removal of some `workaround code <https://github.com/apache/airflow/pull/20759>`_.
+No change in behavior is expected. This was necessary in order to take advantage of a `bugfix <https://github.com/kubernetes-client/python-base/commit/70b78cd8488068c014b6d762a0c8d358273865b4>`_ concerning refreshing of Kubernetes API tokens with EKS, which enabled the removal of some `workaround code <https://github.com/apache/airflow/pull/20759>`_.
XCom now defined by ``run_id`` instead of ``execution_date`` (#20975)
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- As a continuation to the TaskInstance-DagRun relation change started in Airflow 2.2, the ``execution_date`` columns on XCom has been removed from the database, and replaced by an `association proxy <https://docs.sqlalchemy.org/en/13/orm/extensions/associationproxy.html>`_ field at the ORM level. If you access Airflow’s metadata database directly, you should rewrite the implementation to use the ``run_id`` column instead.
+As a continuation to the TaskInstance-DagRun relation change started in Airflow 2.2, the ``execution_date`` columns on XCom has been removed from the database, and replaced by an `association proxy <https://docs.sqlalchemy.org/en/13/orm/extensions/associationproxy.html>`_ field at the ORM level. If you access Airflow’s metadata database directly, you should rewrite the implementation to use the ``run_id`` column instead.
- Note that Airflow’s metadatabase definition on both the database and ORM levels are considered implementation detail without strict backward compatibility guarantees.
+Note that Airflow’s metadatabase definition on both the database and ORM levels are considered implementation detail without strict backward compatibility guarantees.
Non-JSON-serializable params deprecated (#21135).
"""""""""""""""""""""""""""""""""""""""""""""""""
- It was previously possible to use dag or task param defaults that were not JSON-serializable.
+It was previously possible to use dag or task param defaults that were not JSON-serializable.
- For example this worked previously:
+For example this worked previously:
- .. code-block:: python
+.. code-block:: python
- @dag.task(params={"a": {1, 2, 3}, "b": pendulum.now()})
- def datetime_param(value):
- print(value)
+ @dag.task(params={"a": {1, 2, 3}, "b": pendulum.now()})
+ def datetime_param(value):
+ print(value)
- datetime_param("{{ params.a }} | {{ params.b }}")
+ datetime_param("{{ params.a }} | {{ params.b }}")
- Note the use of ``set`` and ``datetime`` types, which are not JSON-serializable. This behavior is problematic because to override these values in a dag run conf, you must use JSON, which could make these params non-overridable. Another problem is that the support for param validation assumes JSON. Use of non-JSON-serializable params will be removed in Airflow 3.0 and until then, use of them will produce a warning at parse time.
+Note the use of ``set`` and ``datetime`` types, which are not JSON-serializable. This behavior is problematic because to override these values in a dag run conf, you must use JSON, which could make these params non-overridable. Another problem is that the support for param validation assumes JSON. Use of non-JSON-serializable params will be removed in Airflow 3.0 and until then, use of them will produce a warning at parse time.
You must use ``postgresql://`` instead of ``postgres://`` in ``sql_alchemy_conn`` for SQLAlchemy 1.4.0+ (#21205)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- When you use SQLAlchemy 1.4.0+, you need to use ``postgresql://`` as the scheme in the ``sql_alchemy_conn``.
- In the previous versions of SQLAlchemy it was possible to use ``postgres://`` , but using it in
- SQLAlchemy 1.4.0+ results in:
+When you use SQLAlchemy 1.4.0+, you need to use ``postgresql://`` as the scheme in the ``sql_alchemy_conn``.
+In the previous versions of SQLAlchemy it was possible to use ``postgres://`` , but using it in
+SQLAlchemy 1.4.0+ results in:
- .. code-block::
+.. code-block::
- > raise exc.NoSuchModuleError(
- "Can't load plugin: %s:%s" % (self.group, name)
- )
- E sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:postgres
+ > raise exc.NoSuchModuleError(
+ "Can't load plugin: %s:%s" % (self.group, name)
+ )
+ E sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:postgres
- If you cannot change the scheme of your URL immediately, Airflow continues to work with SQLAlchemy
- 1.3 and you can downgrade SQLAlchemy, but we recommend updating the scheme.
- Details in the `SQLAlchemy Changelog <https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-3687655465c25a39b968b4f5f6e9170b>`_.
+If you cannot change the scheme of your URL immediately, Airflow continues to work with SQLAlchemy
+1.3 and you can downgrade SQLAlchemy, but we recommend updating the scheme.
+Details in the `SQLAlchemy Changelog <https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-3687655465c25a39b968b4f5f6e9170b>`_.
``auth_backends`` replaces ``auth_backend`` configuration setting (#21472)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- Previously, only one backend was used to authorize use of the REST API. In 2.3 this was changed to support multiple backends, separated by whitespace. Each will be tried in turn until a successful response is returned.
+Previously, only one backend was used to authorize use of the REST API. In 2.3 this was changed to support multiple backends, separated by whitespace. Each will be tried in turn until a successful response is returned.
- This setting is also used for the deprecated experimental API, which only uses the first option even if multiple are given.
+This setting is also used for the deprecated experimental API, which only uses the first option even if multiple are given.
``airflow.models.base.Operator`` is removed (#21505)
""""""""""""""""""""""""""""""""""""""""""""""""""""
- Previously, there was an empty class ``airflow.models.base.Operator`` for “type hinting”. This class was never really useful for anything (everything it did could be done better with ``airflow.models.baseoperator.BaseOperator``), and has been removed. If you are relying on the class’s existence, use ``BaseOperator`` (for concrete operators), ``airflow.models.abstractoperator.AbstractOperator`` (the base class of both ``BaseOperator`` and the AIP-42 ``MappedOperator``), or ``airflow.mod [...]
+Previously, there was an empty class ``airflow.models.base.Operator`` for “type hinting”. This class was never really useful for anything (everything it did could be done better with ``airflow.models.baseoperator.BaseOperator``), and has been removed. If you are relying on the class’s existence, use ``BaseOperator`` (for concrete operators), ``airflow.models.abstractoperator.AbstractOperator`` (the base class of both ``BaseOperator`` and the AIP-42 ``MappedOperator``), or ``airflow.model [...]
Zip files in the DAGs folder can no longer have a ``.py`` extension (#21538)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- It was previously possible to have any extension for zip files in the DAGs folder. Now ``.py`` files are going to be loaded as modules without checking whether it is a zip file, as it leads to less IO. If a ``.py`` file in the DAGs folder is a zip compressed file, parsing it will fail with an exception.
+It was previously possible to have any extension for zip files in the DAGs folder. Now ``.py`` files are going to be loaded as modules without checking whether it is a zip file, as it leads to less IO. If a ``.py`` file in the DAGs folder is a zip compressed file, parsing it will fail with an exception.
``auth_backends`` includes session (#21640)
"""""""""""""""""""""""""""""""""""""""""""
- To allow the Airflow UI to use the API, the previous default authorization backend ``airflow.api.auth.backend.deny_all`` is changed to ``airflow.api.auth.backend.session``, and this is automatically added to the list of API authorization backends if a non-default value is set.
+To allow the Airflow UI to use the API, the previous default authorization backend ``airflow.api.auth.backend.deny_all`` is changed to ``airflow.api.auth.backend.session``, and this is automatically added to the list of API authorization backends if a non-default value is set.
Default templates for log filenames and elasticsearch log_id changed (#21734)
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- In order to support Dynamic Task Mapping the default templates for per-task instance logging has changed. If your config contains the old default values they will be upgraded-in-place.
+In order to support Dynamic Task Mapping the default templates for per-task instance logging has changed. If your config contains the old default values they will be upgraded-in-place.
- If you are happy with the new config values you should *remove* the setting in ``airflow.cfg`` and let the default value be used. Old default values were:
+If you are happy with the new config values you should *remove* the setting in ``airflow.cfg`` and let the default value be used. Old default values were:
- * ``[core] log_filename_template``: ``{{ ti.dag_id }}/{{ ti.task_id }}/{{ ts }}/{{ try_number }}.log``
- * ``[elasticsearch] log_id_template``: ``{dag_id}-{task_id}-{execution_date}-{try_number}``
+* ``[core] log_filename_template``: ``{{ ti.dag_id }}/{{ ti.task_id }}/{{ ts }}/{{ try_number }}.log``
+* ``[elasticsearch] log_id_template``: ``{dag_id}-{task_id}-{execution_date}-{try_number}``
- ``[core] log_filename_template`` now uses "hive partition style" of ``dag_id=<id>/run_id=<id>`` by default, which may cause problems on some older FAT filesystems. If this affects you then you will have to change the log template.
+``[core] log_filename_template`` now uses "hive partition style" of ``dag_id=<id>/run_id=<id>`` by default, which may cause problems on some older FAT filesystems. If this affects you then you will have to change the log template.
- If you have customized the templates you should ensure that they contain ``{{ ti.map_index }}`` if you want to use dynamically mapped tasks.
+If you have customized the templates you should ensure that they contain ``{{ ti.map_index }}`` if you want to use dynamically mapped tasks.
BaseOperatorLink's ``get_link`` method changed to take a ``ti_key`` keyword argument (#21798)
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- In v2.2 we "deprecated" passing an execution date to XCom.get methods, but there was no other option for operator links as they were only passed an execution_date.
+In v2.2 we "deprecated" passing an execution date to XCom.get methods, but there was no other option for operator links as they were only passed an execution_date.
- Now in 2.3 as part of Dynamic Task Mapping (AIP-42) we will need to add map_index to the XCom row to support the "reduce" part of the API.
+Now in 2.3 as part of Dynamic Task Mapping (AIP-42) we will need to add map_index to the XCom row to support the "reduce" part of the API.
- In order to support that cleanly we have changed the interface for BaseOperatorLink to take an TaskInstanceKey as the ``ti_key`` keyword argument (as execution_date + task is no longer unique for mapped operators).
+In order to support that cleanly we have changed the interface for BaseOperatorLink to take an TaskInstanceKey as the ``ti_key`` keyword argument (as execution_date + task is no longer unique for mapped operators).
- The existing signature will be detected (by the absence of the ``ti_key`` argument) and continue to work.
+The existing signature will be detected (by the absence of the ``ti_key`` argument) and continue to work.
``ReadyToRescheduleDep`` now only runs when ``reschedule`` is *True* (#21815)
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- When a ``ReadyToRescheduleDep`` is run, it now checks whether the ``reschedule`` attribute on the operator, and always reports itself as *passed* unless it is set to *True*. If you use this dep class on your custom operator, you will need to add this attribute to the operator class. Built-in operator classes that use this dep class (including sensors and all subclasses) already have this attribute and are not affected.
+When a ``ReadyToRescheduleDep`` is run, it now checks whether the ``reschedule`` attribute on the operator, and always reports itself as *passed* unless it is set to *True*. If you use this dep class on your custom operator, you will need to add this attribute to the operator class. Built-in operator classes that use this dep class (including sensors and all subclasses) already have this attribute and are not affected.
The ``deps`` attribute on an operator class should be a class level attribute (#21815)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- To support operator-mapping (AIP 42), the ``deps`` attribute on operator class must be a set at the class level. This means that if a custom operator implements this as an instance-level variable, it will not be able to be used for operator-mapping. This does not affect existing code, but we highly recommend you to restructure the operator's dep logic in order to support the new feature.
+To support operator-mapping (AIP 42), the ``deps`` attribute on operator class must be a set at the class level. This means that if a custom operator implements this as an instance-level variable, it will not be able to be used for operator-mapping. This does not affect existing code, but we highly recommend you to restructure the operator's dep logic in order to support the new feature.
Deprecation: ``Connection.extra`` must be JSON-encoded dict (#21816)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- TLDR
- ~~~~
+TLDR
+~~~~
- From Airflow 3.0, the ``extra`` field in airflow connections must be a JSON-encoded Python dict.
+From Airflow 3.0, the ``extra`` field in airflow connections must be a JSON-encoded Python dict.
- What, why, and when?
- ~~~~~~~~~~~~~~~~~~~~
+What, why, and when?
+~~~~~~~~~~~~~~~~~~~~
- Airflow's Connection is used for storing credentials. For storage of information that does not
- fit into user / password / host / schema / port, we have the ``extra`` string field. Its intention
- was always to provide for storage of arbitrary key-value pairs, like ``no_host_key_check`` in the SSH
- hook, or ``keyfile_dict`` in GCP.
+Airflow's Connection is used for storing credentials. For storage of information that does not
+fit into user / password / host / schema / port, we have the ``extra`` string field. Its intention
+was always to provide for storage of arbitrary key-value pairs, like ``no_host_key_check`` in the SSH
+hook, or ``keyfile_dict`` in GCP.
- But since the field is string, it's technically been permissible to store any string value. For example
- one could have stored the string value ``'my-website.com'`` and used this in the hook. But this is a very
- bad practice. One reason is intelligibility: when you look at the value for ``extra`` , you don't have any idea
- what its purpose is. Better would be to store ``{"api_host": "my-website.com"}`` which at least tells you
- *something* about the value. Another reason is extensibility: if you store the API host as a simple string
- value, what happens if you need to add more information, such as the API endpoint, or credentials? Then
- you would need to convert the string to a dict, and this would be a breaking change.
+But since the field is string, it's technically been permissible to store any string value. For example
+one could have stored the string value ``'my-website.com'`` and used this in the hook. But this is a very
+bad practice. One reason is intelligibility: when you look at the value for ``extra`` , you don't have any idea
+what its purpose is. Better would be to store ``{"api_host": "my-website.com"}`` which at least tells you
+*something* about the value. Another reason is extensibility: if you store the API host as a simple string
+value, what happens if you need to add more information, such as the API endpoint, or credentials? Then
+you would need to convert the string to a dict, and this would be a breaking change.
- For these reason, starting in Airflow 3.0 we will require that the ``Connection.extra`` field store
- a JSON-encoded Python dict.
+For these reason, starting in Airflow 3.0 we will require that the ``Connection.extra`` field store
+a JSON-encoded Python dict.
- How will I be affected?
- ~~~~~~~~~~~~~~~~~~~~~~~
+How will I be affected?
+~~~~~~~~~~~~~~~~~~~~~~~
- For users of providers that are included in the Airflow codebase, you should not have to make any changes
- because in the Airflow codebase we should not allow hooks to misuse the ``Connection.extra`` field in this way.
+For users of providers that are included in the Airflow codebase, you should not have to make any changes
+because in the Airflow codebase we should not allow hooks to misuse the ``Connection.extra`` field in this way.
- However, if you have any custom hooks that store something other than JSON dict, you will have to update it.
- If you do, you should see a warning any time that this connection is retrieved or instantiated (e.g. it should show up in
- task logs).
+However, if you have any custom hooks that store something other than JSON dict, you will have to update it.
+If you do, you should see a warning any time that this connection is retrieved or instantiated (e.g. it should show up in
+task logs).
- To see if you have any connections that will need to be updated, you can run this command:
+To see if you have any connections that will need to be updated, you can run this command:
- .. code-block:: shell
+.. code-block:: shell
- airflow connections export - 2>&1 >/dev/null | grep 'non-JSON'
+ airflow connections export - 2>&1 >/dev/null | grep 'non-JSON'
- This will catch any warnings about connections that are storing something other than JSON-encoded Python dict in the ``extra`` field.
+This will catch any warnings about connections that are storing something other than JSON-encoded Python dict in the ``extra`` field.
The ``tree`` default view setting has been renamed to ``grid`` (#22167)
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- If you set the ``dag_default_view`` config option or the ``default_view`` argument to ``DAG()`` to ``tree`` you will need to update your deployment. The old name will continue to work but will issue warnings.
+If you set the ``dag_default_view`` config option or the ``default_view`` argument to ``DAG()`` to ``tree`` you will need to update your deployment. The old name will continue to work but will issue warnings.
Database configuration moved to new section (#22284)
""""""""""""""""""""""""""""""""""""""""""""""""""""
- The following configurations have been moved from ``[core]`` to the new ``[database]`` section. However when reading the new option, the old option will be checked to see if it exists. If it does a DeprecationWarning will be issued and the old option will be used instead.
-
- * sql_alchemy_conn
- * sql_engine_encoding
- * sql_engine_collation_for_ids
- * sql_alchemy_pool_enabled
- * sql_alchemy_pool_size
- * sql_alchemy_max_overflow
- * sql_alchemy_pool_recycle
- * sql_alchemy_pool_pre_ping
- * sql_alchemy_schema
- * sql_alchemy_connect_args
- * load_default_connections
- * max_db_retries
+The following configurations have been moved from ``[core]`` to the new ``[database]`` section. However when reading the new option, the old option will be checked to see if it exists. If it does a DeprecationWarning will be issued and the old option will be used instead.
+
+* sql_alchemy_conn
+* sql_engine_encoding
+* sql_engine_collation_for_ids
+* sql_alchemy_pool_enabled
+* sql_alchemy_pool_size
+* sql_alchemy_max_overflow
+* sql_alchemy_pool_recycle
+* sql_alchemy_pool_pre_ping
+* sql_alchemy_schema
+* sql_alchemy_connect_args
+* load_default_connections
+* max_db_retries
Remove requirement that custom connection UI fields be prefixed (#22607)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- Hooks can define custom connection fields for their connection type by implementing method ``get_connection_form_widgets``. These custom fields appear in the web UI as additional connection attributes, but internally they are stored in the connection ``extra`` dict field. For technical reasons, previously, when stored in the ``extra`` dict, the custom field's dict key had to take the form ``extra__<conn type>__<field name>``. This had the consequence of making it more cumbersome to [...]
+Hooks can define custom connection fields for their connection type by implementing method ``get_connection_form_widgets``. These custom fields appear in the web UI as additional connection attributes, but internally they are stored in the connection ``extra`` dict field. For technical reasons, previously, when stored in the ``extra`` dict, the custom field's dict key had to take the form ``extra__<conn type>__<field name>``. This had the consequence of making it more cumbersome to de [...]
- To enable this, update the dict returned by the ``get_connection_form_widgets`` method to remove the prefix from the keys. Internally, the providers manager will still use a prefix to ensure each custom field is globally unique, but the absence of a prefix in the returned widget dict will signal to the Web UI to read and store custom fields without the prefix. Note that this is only a change to the Web UI behavior; when updating your hook in this way, you must make sure that when you [...]
+To enable this, update the dict returned by the ``get_connection_form_widgets`` method to remove the prefix from the keys. Internally, the providers manager will still use a prefix to ensure each custom field is globally unique, but the absence of a prefix in the returned widget dict will signal to the Web UI to read and store custom fields without the prefix. Note that this is only a change to the Web UI behavior; when updating your hook in this way, you must make sure that when your [...]
The webserver.X_FRAME_ENABLED configuration works according to description now (#23222).
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- In Airflow 2.0.0 - 2.2.4 the webserver.X_FRAME_ENABLED parameter worked the opposite of its description,
- setting the value to "true" caused "X-Frame-Options" header to "DENY" (not allowing Airflow to be used
- in an IFrame). When you set it to "false", the header was not added, so Airflow could be embedded in an
- IFrame. By default Airflow could not be embedded in an IFrame.
+In Airflow 2.0.0 - 2.2.4 the webserver.X_FRAME_ENABLED parameter worked the opposite of its description,
+setting the value to "true" caused "X-Frame-Options" header to "DENY" (not allowing Airflow to be used
+in an iframe). When you set it to "false", the header was not added, so Airflow could be embedded in an
+iframe. By default Airflow could not be embedded in an iframe.
- In Airflow 2.2.5 there was a bug introduced that made it impossible to disable Airflow to
- work in IFrame. No matter what the configuration was set, it was possible to embed Airflow in an IFrame.
+In Airflow 2.2.5 there was a bug introduced that made it impossible to disable Airflow to
+work in iframe. No matter what the configuration was set, it was possible to embed Airflow in an iframe.
- Airflow 2.3.0 restores the original meaning to the parameter. If you set it to "true" (default) Airflow
- can be embedded in an IFrame (no header is added), but when you set it to "false" the header is added
- and Airflow cannot be embedded in an IFrame.
+Airflow 2.3.0 restores the original meaning to the parameter. If you set it to "true" (default) Airflow
+can be embedded in an iframe (no header is added), but when you set it to "false" the header is added
+and Airflow cannot be embedded in an iframe.
New Features
@@ -302,7 +302,7 @@ Improvements
- Enable use of custom conn extra fields without prefix (#22607)
- Initialize finished counter at zero (#23080)
- Improve logging of optional provider features messages (#23037)
-- Meaningful error mssage in resolve_template_files (#23027)
+- Meaningful error message in resolve_template_files (#23027)
- Update ImportError items instead of deleting and recreating them (#22928)
- Add option ``--skip-init`` to db reset command (#22989)
- Support importing connections from files with ".yml" extension (#22872)
@@ -325,7 +325,7 @@ Improvements
- Expose ``try_number`` in airflow vars (#22297)
- Add generic connection type (#22310)
- Add a few more fields to the taskinstance finished log message (#22262)
-- Pause autorefresh if scheduler isn't running (#22151)
+- Pause auto-refresh if scheduler isn't running (#22151)
- Show DagModel details. (#21868)
- Add pip_install_options to PythonVirtualenvOperator (#22158)
- Show import error for ``airflow dags list`` CLI command (#21991)
@@ -363,7 +363,7 @@ Improvements
- Add "Greater/Smaller than or Equal" to filters in the browse views (#20602) (#20798)
- Rewrite DAG run retrieval in task command (#20737)
- Speed up creation of DagRun for large DAGs (5k+ tasks) by 25-130% (#20722)
-- Make native environment Airflow-flavoured like sandbox (#20704)
+- Make native environment Airflow-flavored like sandbox (#20704)
- Better error when param value has unexpected type (#20648)
- Add filter by state in DagRun REST API (List Dag Runs) (#20485)
- Prevent exponential memory growth in Tasks with custom logging handler (#20541)
@@ -374,14 +374,14 @@ Improvements
- UI: Update duration column for better human readability (#20112)
- Use Viewer role as example public role (#19215)
- Properly implement DAG param dict copying (#20216)
-- ``ShortCircuitOperator`` push XCom by returnung python_callable result (#20071)
+- ``ShortCircuitOperator`` push XCom by returning python_callable result (#20071)
- Add clear logging to tasks killed due to a Dagrun timeout (#19950)
- Change log level for Zombie detection messages (#20204)
- Better confirmation prompts (#20183)
- Only execute TIs of running DagRuns (#20182)
- Check and run migration in commands if necessary (#18439)
- Log only when Zombies exists (#20118)
-- Inrease length of the email and username (#19932)
+- Increase length of the email and username (#19932)
- Add more filtering options for TI's in the UI (#19910)
- Dynamically enable "Test Connection" button by connection type (#19792)
- Avoid littering postgres server logs with "could not obtain lock" with HA schedulers (#19842)
@@ -482,7 +482,7 @@ Bug Fixes
- Fix parsing of Cloudwatch log group arn containing slashes (#14667) (#19700)
- Sanity check for MySQL's TIMESTAMP column (#19821)
- Allow using default celery command group with executors subclassed from Celery-based executors. (#18189)
-- Move ``class_permission_name`` to mixin so it applies to all auths (#18749)
+- Move ``class_permission_name`` to mixin so it applies to all classes (#18749)
- Adjust trimmed_pod_id and replace '.' with '-' (#19036)
- Pass custom_headers to send_email and send_email_smtp (#19009)
- Ensure ``catchup=False`` is used in example dags (#19396)
@@ -527,21 +527,21 @@ Misc/Internal
- Replace usage of ``DummyOperator`` with ``EmptyOperator`` (#22974)
- Deprecate ``DummyOperator`` in favor of ``EmptyOperator`` (#22832)
- Remove unnecessary python 3.6 conditionals (#20549)
-- Bump moment from 2.29.1 to 2.29.2 in /airflow/www (#22873)
-- Bump prismjs from 1.26.0 to 1.27.0 in /airflow/www (#22823)
-- Bump nanoid from 3.1.23 to 3.3.2 in /airflow/www (#22803)
-- Bump minimist from 1.2.5 to 1.2.6 in /airflow/www (#22798)
+- Bump ``moment`` from 2.29.1 to 2.29.2 in /airflow/www (#22873)
+- Bump ``prismjs`` from 1.26.0 to 1.27.0 in /airflow/www (#22823)
+- Bump ``nanoid`` from 3.1.23 to 3.3.2 in /airflow/www (#22803)
+- Bump ``minimist`` from 1.2.5 to 1.2.6 in /airflow/www (#22798)
- Remove dag parsing from db init command (#22531)
- Update our approach for executor-bound dependencies (#22573)
- Use ``Airflow.Base.metadata`` in FAB models (#22353)
-- Limit Docutils to make our documentation pretty again (#22420)
+- Limit docutils to make our documentation pretty again (#22420)
- Add Python 3.10 support (#22050)
- [FEATURE] add 1.22 1.23 K8S support (#21902)
- Remove pandas upper limit now that SQLA is 1.4+ (#22162)
- Patch ``sql_alchemy_conn`` if old postgres scheme used (#22333)
- Protect against accidental misuse of XCom.get_value() (#22244)
- Order filenames for migrations (#22168)
-- Don't try to create automigration for celery tables (#22120)
+- Don't try to auto generate migrations for Celery tables (#22120)
- Require SQLAlchemy 1.4 (#22114)
- bump sphinx-jinja (#22101)
- Add compat shim for SQLAlchemy to avoid warnings (#21959)
@@ -549,9 +549,9 @@ Misc/Internal
- Deprecate non-JSON ``conn.extra`` (#21816)
- Bump upper bound version of ``jsonschema`` to 5.0 (#21712)
- Deprecate helper utility ``days_ago`` (#21653)
-- Remove ```:type``` lines now sphinx-autoapi supports typehints (#20951)
-- Quelch deprecation warning in tests (#20900)
-- Use ``DagRun.run_id`` instead of ``execution_date`` when updating state of TIs(UI & REST API) (#18724)
+- Remove ```:type``` lines now ``sphinx-autoapi`` supports type hints (#20951)
+- Silence deprecation warning in tests (#20900)
+- Use ``DagRun.run_id`` instead of ``execution_date`` when updating state of TIs (UI & REST API) (#18724)
- Add Context stub to Airflow packages (#20817)
- Update Kubernetes library version (#18797)
- Rename ``PodLauncher`` to ``PodManager`` (#20576)
diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt
index 77964e0bf5..b9f2aad173 100644
--- a/docs/spelling_wordlist.txt
+++ b/docs/spelling_wordlist.txt
@@ -352,6 +352,7 @@ Sagemaker
Sasl
SearchResultGenerator
SecretManagerClient
+SecurityManager
Seedlist
Sendgrid
SerializedDAG
@@ -632,6 +633,7 @@ configfile
configmap
configmaps
configs
+configurability
conftest
conn
connectTimeoutMS
@@ -659,6 +661,7 @@ csv
ctor
cubeName
customDataImportUids
+customizability
customizable
customizations
cx
@@ -820,6 +823,7 @@ filesize
filesystem
filesystems
filetype
+finalizers
findall
firstname
fluentd
@@ -911,6 +915,7 @@ iam
idempotence
idempotency
ie
+iframe
ignorable
ignoreUnknownValues
imageORfile
@@ -922,6 +927,7 @@ imgcat
impyla
incompliancies
inexhaustive
+inferral
infile
influxdb
infoType
@@ -1045,6 +1051,7 @@ milton
minicluster
minikube
misconfigured
+mixin
mixup
mkdir
mkdirs
@@ -1137,6 +1144,7 @@ passwd
pathType
pem
performant
+permalinks
personalizations
pformat
picklable
@@ -1243,6 +1251,7 @@ reinit
reinitialization
relativedelta
remoting
+renderers
renewer
replicaSet
repo
@@ -1461,6 +1470,7 @@ tsv
ttl
tunables
txt
+typeahead
tz
tzinfo
ui