Hello Everyone,

As a follow-up to AIP-51 - when it is completed (with few more quirks
like the one described by Andrey in the "Rendered Task Instance
Fields" discussion) - it should now be entirely possible to move
Kubernetes Executor, Celery Executor and related "joined" executors to
respective providers.

There is of course question where to move CeleryKubernetesExecutor,
but we have prior art with Transfer Operators and we might choose to
add it to "cncf.kubernetes" and make the celery provider an optional
dependency of K8S provider.

This has multiple advantages, and one of the biggest one I can think
of is that we could evolve K8S executor faster than Airflow itself and
we would avoid quite a lot of complexities involved in parallel
modifications of K8S code in provider and executor (it happened in the
past that we had do to add very high min-airflow version for
"cncf.kubernetes" provider in order to make this happens, and we could
likely avoid similar problems by making sure K8S executor is used as
"yet another executor" - compliant with the AIP-51 interface and we
could evolve it much faster.

That would also give celery provider some "real" meaning - so far
celery provider was merely exposing celery queue sensor, but when we
move CeleryExecutor to the provider, the provider would finally be a
useful one.

Doing this requires a few small things:
* we likely need to add dynamic import in the old "executors" package
following PEP 562 (and the way we've done operators) and deprecation
notice in case someone uses them from there.
* we likely need to add "cncf.kubernetes" and "celery" packages as
pre-installed providers - alongside http, fttp, common.sql, sqlite,
imap.

I **think**, after AIP-51 gets implemented, this would be a fully
backwards-compatible change - it's just a matter of proper management
of the dependencies. We could add min-cncf.kubernetes/celery versions
in Airflow 2.6, so that we are sure 2.6+ airflow uses only newer
providers and kubernetes/celery code and this would be fully
transparent for the users, I believe.

J.

Reply via email to