This is an automated email from the ASF dual-hosted git repository. jedcunningham pushed a commit to branch v2-2-test in repository https://gitbox.apache.org/repos/asf/airflow.git
commit 74ff37cb2cd62f2a6e356ddee5a7b78366fa0b82 Author: Lewis John McGibbney <[email protected]> AuthorDate: Thu Feb 3 08:50:25 2022 -0800 Augment xcom docs (#20755) (cherry picked from commit 40d3a76a9bce2360b951f2e990cba571c5f51a76) --- docs/apache-airflow/concepts/xcoms.rst | 40 +++++++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/docs/apache-airflow/concepts/xcoms.rst b/docs/apache-airflow/concepts/xcoms.rst index eb11ff7..57b9e54 100644 --- a/docs/apache-airflow/concepts/xcoms.rst +++ b/docs/apache-airflow/concepts/xcoms.rst @@ -42,8 +42,8 @@ XComs are a relative of :doc:`variables`, with the main difference being that XC Note: If the first task run is not succeeded then on every retry task XComs will be cleared to make the task run idempotent. -Custom Backends ---------------- +Custom XCom Backends +-------------------- The XCom system has interchangeable backends, and you can set which backend is being used via the ``xcom_backend`` configuration option. @@ -51,4 +51,38 @@ If you want to implement your own backend, you should subclass :class:`~airflow. There is also an ``orm_deserialize_value`` method that is called whenever the XCom objects are rendered for UI or reporting purposes; if you have large or expensive-to-retrieve values in your XComs, you should override this method to avoid calling that code (and instead return a lighter, incomplete representation) so the UI remains responsive. -You can also override the ``clear`` method and use it when clearing results for given dags and tasks. This allows the custom XCom backend process the data lifecycle easier. +You can also override the ``clear`` method and use it when clearing results for given dags and tasks. This allows the custom XCom backend to process the data lifecycle easier. + +Working with Custom XCom Backends in Containers +----------------------------------------------- + +Depending on where Airflow is deployed i.e., local, Docker, K8s, etc. it can be useful to be assured that a custom XCom backend is actually being initialized. For example, the complexity of the container environment can make it more difficult to determine if your backend is being loaded correctly during container deployment. Luckily the following guidance can be used to assist you in building confidence in your custom XCom implementation. + +Firstly, if you can exec into a terminal in the container then you should be able to do: + +.. code-block:: python + + from airflow.models.xcom import XCom + + print(XCom.__name__) + +which will print the actual class that is being used. + +You can also examine Airflow's configuration: + +.. code-block:: python + + from airflow.settings import conf + + conf.get("core", "xcom_backend") + +Working with Custom Backends in K8s via Helm +-------------------------------------------- + +Running custom XCom backends in K8s will introduce even more complexity to you Airflow deployment. Put simply, sometimes things go wrong which can be difficult to debug. + +For example, if you define a custom XCom backend in the Chart ``values.yaml`` (via the ``xcom_backend`` configuration) and Airflow fails to load the class, the entire Chart deployment will fail with each pod container attempting to restart time and time again. + +When deploying in K8s your custom XCom backend needs to be reside in a ``config`` directory otherwise it cannot be located during Chart deployment. + +An observed problem is that it is very difficult to acquire logs from the container because there is a very small window of availability where the trace can be obtained. The only way you can determine the root cause is if you are fortunate enough to query and acquire the container logs at the right time. This in turn prevents the entire Helm chart from deploying successfully.
