Q: Do we want to pre-install Dask provider in Airflow 2.7.0 (with Dask
executor) once separated ?
Discussion was here:
https://lists.apache.org/thread/0d9x4kl7hc2qzvho2mbdf35ohn5w12l6
Please vote:
* +1 -> yes, we want to have dask provider preinstalled
* -1 -> no, it's fine to make it optional
Hello everyone,
TL;DR; I wanted to discuss one aspect of the "configuration" separation
between core and providers that I was working on while moving executors to
providers - namely : can providers contribute configuration options in
"core" sections of configuration.
It is almost complete and we
My opinion is I would rather not preinstall Dask provider because as already
mentioned in this thread, this is not technically a breaking change. Users
using Dask provider will be able to find out quite easily that their
environment is not working without Dask dependency. To me it makes more
> I guess the question is not "can we do it" but more "should we do it" :D
right :)
Yes. I quite agree.
We discussed it that "dependencies" are not "bound" by semver. And I think
technically we **could** make `dask` non-preinstalled without breaking
Semver. Similarly we could - and maybe even will (after AIP-56) have FAB as
an optional provider.
For me this is really the way
Just on the question of semver, I am not convinced that semver prohibits
this.
As a user, your concerns and expectations regarding semver are about
essentially how the code works, e.g. are you going to have to refactor all
of your 500 dags. In other words the API.. But to me this is a lower
Do we know how many of those affected operators have "wait=False" by
default? I think that should help us to determine the action. The
"default_deferrable" is an option that has not been advertised (and it is
not yet in config published in any released airflow version, so it is not
yet "officially
Ok. I am ok with leaving Dask preinstalled, I think we will already benefit
from moving it to provider and moving tests to the provider tests.
On Fri, Jul 14, 2023 at 3:08 PM Hussein Awala wrote:
> We all agree on moving the 5 remote executors to their respective
> providers. The main question
+1 (binding).
On Mon, Jul 17, 2023 at 7:56 PM Damian Shaw
wrote:
> +1 (Non-binding)
>
> Although I would like to see some version of the proposed "SlaTask"
> workaround included in Airflow itself so that:
> 1) Tests can be added to make sure other Airflow changes don't
> break
+1 (binding)
On 2023/07/17 05:45:26 Elad Kalif wrote:
> Hey all,
>
>
> I have just cut the Elasticsearch RC3 Airflow Provider package. This email
> is calling a vote on the release,
>
> which will last for 72 hours - which means that it will end on July 20,
> 2023 05:45 AM UTC and until 3
+1 (binding): checked licences, sources, checksums, signatures - all looks
good.
On Thu, Jul 20, 2023 at 12:11 PM Ankit Chaurasia
wrote:
> +1 (non-binding)
>
>
>
>
>
>
>
> On Wed, Jul 19, 2023 at 12:35 PM Utkarsh Sharma
> wrote:
>
> > +1 (non-binding)
> >
> >
+1 (non-binding)
On Wed, Jul 19, 2023 at 12:35 PM Utkarsh Sharma
wrote:
> +1 (non-binding)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> For additional commands, e-mail: dev-h...@airflow.apache.org
12 matches
Mail list logo
