I like what Daniel suggested. But I guess we’ll probably need to split a few
executors from existing providers for this? If that’s the case, are we going to
have those executors exist in both side for some time? or is there a better for
it?
Best,
Wei
> On Sep 17, 2024, at 1:16 AM, Jens Scheffl
Hi all,
yes, diverged a bit. I'll add an agenda item for the next Airflow 3 dev
call.
Main question as outcome would be: Shall we split the Providers if we
are (ongoing) also planning to split the deployment dependencies of
Scheduler, Worker, Webserver etc?
-->
https://cwiki.apache.org/confluen
A sortof third option...
Seems there could be good reason to release executor separately
e.g.
`apache-airflow-providers-aws-executors`
Separate from the dag authoring stuff. So e.g. with cncf you could stick
with old dag authoring stuff but stay on latest k8s executor.
On Mon, Sep 16, 2024 at
On one side it makes sense to me, and I actually like the thinking "providers
should only be for DAG authors". That makes it simple to figure whether
something should belong to providers. If we go that way then FAB would no
longer be a provider but a plugin which would be one step closer to not
> Provider package name: "edge", so gets to package "airflow.providers.edge"
I'm not so sure about this name. I have no problems with the"edge" part, I am
mostly questioning if this should be a provider, or should it be another kind
of module. For instance it won't have an Operator, Sensor or Ho
Hi Devs,
as we had a naming discussion for AIP-69 in
https://lists.apache.org/thread/br1jfoc8p1wjzk74c09srjgr29spytfy and PRs
are ready, Elad proposed to have at least a lazy consensus to close the
naming before merge.
Not having real counts leave "Distributed" and "Edge" close-by with most
posi
