PR https://github.com/apache/airflow/pull/47146 to depreciate the
parameters in Airflow 3
I believe this closes the discussion on that topic for now
On Sun, Feb 9, 2025 at 8:34 AM Elad Kalif wrote:
> OK so this is the first case (I think?) of item that we want to deprecate
> in Airflow 3 rather
OK so this is the first case (I think?) of item that we want to deprecate
in Airflow 3 rather than remove.
I raised https://github.com/apache/airflow/pull/46594 to
introduce RemovedInAirflow4Warning so we can use it to indicate the
parameters are deprecated but still supported.
On Fri, Feb 7, 2025
+100 to what Jarek and Michal said. Changing DAG code for this will seriously
impact Airflow 3 adoption.
We can move the code to a provider without having to change the DAG Author
interface can’t we? For instance we can change the DAG parser to convert these
options in to an SMTP notifier can’t
I think we have already implemented many code changes. I'm not sure I
understand why this change would be more painful than the others. However, I
don’t have a strong opinion on this one. I just want to remind everyone that if
we decide to make breaking changes, please remember to include a sign
I agree with Michał - it's not how simple it is, but that you do it at all.
Chance is that if you have 1000s of DAGs in your company and some of them
use email notification, it means that vast majority of them will. And I
already know of companies where there are 20+ teams working on those and
havi
I am concerned simply because it is a physical code change, and one that
would affect a good percentage of DAGs out there. No matter how complex the
change is, it forces the users to modify their code, which is huge
operational overhead in bigger organizations. Imagine - there could be a
central pl
I'd like to provide example:
with DAG(
default_args={
"email": ["airf...@airflow.com"],
"email_on_failure": True,
"email_on_retry": True,
},
...
) as dag:
becomes:
from airflow.providers.smtp.notifications.smtp import SmtpNotifier
with DAG(
default_args={
+1 to what Jarek proposes.
IMO, for Airflow to become not only a leading solution in its market, but
also a de facto standard, we need to be super conscious about the effort
required for users to maintain it and keep it up to date. It's a super
common concern raised by the users, especially those,
I'd say - if it is a very used feature, and likely a lot of people use it,
the only way we can justify that change is if we can fully automate it with
near 100% certainty. This is one of the reasons we did not want to do
Templating change as breaking in 3.0 - because it was unlikely to be fully
au
> But the cost is forcing all users of this popular feature to modify
source code of their DAGs, putting another hurdle for Airflow 3 adoption.
We're all Airflow users before being maintainers and contributors, so I
understand how difficult it can be to update code for a library upgrade.
However,
>Actually, modifying DAGs code is the easiest part of the migration
I strongly disagree. Modifying source code of DAGs might be easy for
individual devs, but it is what blocks customers who have significant size
deployments from perfoming upgrades and migrations. Even if the code change
is seeming
I vote for option 1. complete removal.
Email is just another integration. We should not favor it.
I agree with Michal that it's massively used but I do not agree on the risk.
>From my point of view, the SmtpNotifier (Which has templates! thanks to
https://github.com/apache/airflow/pull/36226) ha
> avoiding forcing users to modify their DAGs code
Actually, modifying DAGs code is the easiest part of the migration
for users, because we will provide migration rules via ruff. For more
details, please see https://github.com/apache/airflow/issues/41641.
On Mon, Jan 27, 2025 at 11:01 PM Michał M
Email notifications are a *massively* used Airflow feature. I suggest that
any change does not break the current syntax of BaseOperator, avoiding
forcing users to modify their DAGs code. Changes on the config side and
provider separation should be fine though (seems separating provider while
keepin
Hello everyone!
We had an implicit consensus about removing the email/SMTP integration from
Airflow Core and replacing it with the SMTP provider and SmtpNotifier. This
change will simplify Airflow's core, improve maintainability, and provide a
more consistent experience with other providers. Now i
15 matches
Mail list logo
