alright handling the potential issues like adults, then I
> think it's a solid idea. I've just seen too many groups of grown adults
> devolve into children when they perceive favoritism or bias.
>
>
> - ferruzzi
>
>
>
> From: Jarek Pot
Hello everyone,
Here is a formal ask for consensus on the new process of suspending
some providers that hold us back from upgrading old dependencies.
It has been discussed in
https://lists.apache.org/thread/j98bgw9jo7xr4fvjh27d6bfoyxr1omcm and
since it seems we have a consensus, I am calling for
he organization. Do not
> > > click links or open attachments unless you can confirm the sender and
> > know
> > > the content is safe.
> > >
> > >
> > >
> > > Yeah agreed.
> > >
> > > Each provider should be treated like a sep
Maybe just `NukeOperator` simply :)
On Tue, Mar 28, 2023 at 7:57 AM Daniel Standish
wrote:
>
> Happy to see the engagement on this one. Thanks to everyone for thinking
> it through and contributing their thoughts.
>
> re niko
>
>
> > - Context managers:
> > I found most of the context manager
I just corrected the milestone in 29112 to 2.6.0
the milestone was moved to 2.6 when we decided not to cherry-pick that
one and moved it to 2.6.0 (task long handler in main branch is vastly
different than the one in 2.5 after Daniel's change so this one does
not cleanly cherry-pick and we
we should allow ShortCircuit to "short
> circuit" the teardowns [either by default or perhaps optionally with a
> skip_teardowns_too param] and document with examples? Or are you saying
> shortcircuit operator should be updated so it's not possible to use it to
> skip a teardown?
>
My view:
1) I am not sure if we should make it private (I am not even sure what
it would mean to be private:) ). But If it means that setting the rule
type for non-teardown task should raise an error (and of course
documenting this rule as only (and automatically) being applied to
teardown task -
Hello Everyone,
TL;DR; I wanted to raise a discussion and make a proposal about option
to skip some niche providers of our from releasing if they are holding
us back, regarding the dependencies
We are going through some troubles with dependencies of our providers
- mostly around some outdated
I am not sure if it needs an AIP - just PR implementing it and
discussion there should be more than enough IMHO.
On Thu, Mar 23, 2023 at 10:51 AM Malthe wrote:
>
> This AIP comes out of a previous discussion on skipping tasks based on
> a rule-based schedule, e.g. excluding holidays except if
Two comments here as well (just technical rather than whether we
should do it or not) - to clarify maybe what the proposal really is.
Hussein:
Yeah I had exactly the same thoughts and that was even my original
response in the PR
Yep I think we are all converging.
I **think** the context manager is good (and I saw it initially in the
doc from Daniel) and I tend to agree this (or similar) syntactic sugar
will be the way people will interact with setup/teardown.
I personally believe there are two slightly independent
The "update-provider-dependencies" is the right pre-commit name BTW,
not "generate...".
On Fri, Mar 24, 2023 at 6:47 PM Jarek Potiuk wrote:
>
> The provider.yaml is the source of information, but when you install
> application via setup.py locally after changi
The provider.yaml is the source of information, but when you install
application via setup.py locally after changing it, you need to
generate the "generated/provider_dependencies.json" - this is the file
that is used by setup.py when you install it via ".[extras]". This
file will get automatically
prespective if we don't address the issue directly (general solution
> > to top level code issues) any attempt to minimize it must come with a clear
> > way of letting users know what is going on.
> >
> > בתאריך יום ו׳, 24 במרץ 2023, 12:37, מאת Jarek Potiuk :
> > >
Added :)
On Fri, Mar 24, 2023 at 4:30 AM Bowrna Prabhakaran wrote:
>
> Can I get added to the invitation as well? (mailbow...@gmail.com)
> Thanks
>
> On Fri, Mar 24, 2023 at 2:37 AM Jarek Potiuk wrote:
>
> > did
> >
> > On Thu, Mar 23, 2023 at 9:22 PM c
TL;DR; I am in favour of the change (limiting it to DagFileProcessor
only) and turning using Variables at top-level as good practice
(2.6+).
Here is why.
I partially agree with Elad /Ash, but I am not 0/1 on that subject any
more. I think there is a more nuanced approach that we could take
here.
did
On Thu, Mar 23, 2023 at 9:22 PM c c wrote:
>
> Can I be added to the invitation as well(changcheng12...@gmail.com)?
> thanks!
>
> On Thu, Mar 23, 2023 at 12:59 PM Jarek Potiuk wrote:
>
> > I added all those who asked. It's really cool we have so much interest :)
Disclaimer - I've spent some time with Daniel discussing the options
and brainstorming some consequences of the change over the last few
days (er... evenings) and that was quite a brain-teaser. So I
perfectly understand if it takes time and effort to digest.
But here is the digest of my thoughts
I added all those who asked. It's really cool we have so much interest :).
Julien, Maciej: NO PRESSURE
-
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org
tronomer.io
> > Julien
> >
> > On Thu, Mar 16, 2023 at 8:21 PM Julien Le Dem
> > wrote:
> >
> > > We are planning to do this session next Thursday at 5pm CET 9am PT. I
> > will
> > > send a zoom link in advance.
> > > Julien
> &g
time' off data_interval_en, or
> dag start time, task start time, or take different actions based on SLA
> breach, or have multiple levels of breaches e.g. "yellow", "red")
>
> Thanks for being receptive to these concerns.
>
> Damian
>
>
> --
e resources.
>
>
>
>
>
> Thanks a lot!
>
>
>
> Best regards
>
> David Sanchez Plaza
>
>
>
> Huawei Cloud Business Dept, International Cloud & AI
>
> David Sanchez Plaza - 大卫
>
> Huawei HCIE Cloud Service Solutions Architect (Link)
>
a different SLA of 3 hours for
> > a different task in the same DAG. As a DAG may contain many 1000s of tasks
> > but only a small subset of be critical enough to warrant an SLA, I imagine
> > this would be a widespread use case. Am I understanding it correctly that
> >
Added you, Sung Yun
-
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org
Hello David.
I think you should first review the discussions we kept on having for at
least the last half a year about accepting donations of "service" bound
providers from the teams of those services. General consensus is that we
are extremely reluctant to get new providers added as part of the
sation / who this is replying to and I don't
> see a new AIP yet, is this still in progress?
>
> I would definitely want to be able provide feedback on an AIP for SLAs, while
> the current SLA system is limited I am making heavy usage of it.
>
> -Original Message-----
> From: J
> Jarek - thank you for the suggestions - those are great suggestions in
> enhancing the proposal... Regarding your first point - how does deprecating
> an existing feature work for Airflow? Do we need to give a grace period of a
> minor or major patch over which we continue to support the
n, we are
> definitely safe from introducing complexity.
>
> As for the statsd and dogstatsd capability, we should obviously maintain it
> for the backward compatibility, but I do agree that OTEL should be the
> definite choice by default.
>
> On Sun, Mar 12, 2023 at 11:50 AM Jarek P
rrectly register all our fixtures we do not need to change
> > anything related to them in our code.
> > In case of utilities we need to change imports from from tests.test_utils
> > import awesome_stuff to from some_awesome_name.utils import awesome_stuff
> >
> >
&
es
> (though it's worth nothing that the DAG file is executed/parsed every time a
> task runs, the result is just not stored in the DB for those)
> Thoughts?
> Ash
>
> On Mar 17 2023, at 5:30 am, Jarek Potiuk wrote:
> > Thanks Sung Yun,
> >
> > Fantastic docum
Thanks Sung Yun,
Fantastic document!
This is one incredibly well thought out document and proposal. I like
the detailed analysis of the problem (finally it answers very clearly
and explicitly why the current SLA mechanism is essentially broken).
It also very well reflects the changes in our
Hello Airflow Community,
I have the pleasure to announce that The Project Management Committee
(PMC) for Apache Airflow has invited Pierre Jeambrun to become Apache
Airflow PMC Member and we are pleased to announce that he has kindly
accepted it.
Being a PMC member enables assistance with the
Hello Airflow Community,
I have the pleasure to announce that The Project Management Committee
(PMC) for Apache Airflow has invited Brent Bovenzi to become Apache
Airflow PMC Member and we are pleased to announce that he has kindly
accepted it.
Being a PMC member enables assistance with the
+1 (binding) checked signatures, checksums, licences.
On Tue, Mar 14, 2023 at 7:23 AM Pankaj Singh wrote:
>
> +1 (non-binding)
>
> On Tue, Mar 14, 2023 at 5:29 AM Hussein Awala wrote:
>
> > +1 (non-binding)
> >
> >
> > From: Josh Fell
> > Sent: Tuesday, March
I think that is a good point but I have a conceptually different
proposal. From the coding perspective it might be similar in terms of
implementation and complexity, but long term it will much better
reflect the way how "Airflow as a Platform" currently is implemented.
My proposal is very close
+1 (binding) Checked licences, signatures, checksums, tested all my
fixes and where possible I confirmed they are working (and asked
reporters to double-check where it is not easy/possible - status in
https://github.com/apache/airflow/issues/30028
On Sun, Mar 12, 2023 at 7:47 AM Elad Kalif
There you go: https://github.com/apache/airflow/issues/3
Congrats to Paulo Barros for opening the 30.000th issue/pr in Airflow.
-
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail:
done
On Tue, Mar 7, 2023 at 7:56 AM person wrote:
>
> Hello,
>
> Writing in regards to this; "You will need to request edit access to the
> Confluence page in order to create your AIP document" may you grant me
> access?
>
> Email: thirdsea...@gmail.com
> Login: thirdseason
>
> Thanks kindly
+1 binding. Checks licence, signature, checksum.
On Tue, Mar 7, 2023 at 6:02 PM Kaxil Naik wrote:
>
> +1 binding
>
> On Tue, 7 Mar 2023 at 13:04, Hussein Awala wrote:
>
> > +1 (non-binding)
> >
> >
> > From: Elad Kalif
> > Sent: Tuesday, March 7, 2023 9:26:17
+1
On Tue, Mar 7, 2023 at 1:11 PM Pierre Jeambrun wrote:
>
> Hello,
>
> I don’t think we had a lazy consensus on this matter but we already applied
> it a couple of times before (for 2.5.1 and another one before that, if I am
> not mistaken).
>
> I think it would be good to start a lazy
Calling for committers who would like to become mentors in GSOC - I
think it's a great experience to be a mentor, so if you would like to
become one - please request the acknowledgment (see below).
Also if you have some ideas for projects for GSOC for airflow, please
let me know :).
J.
+1 (binding) - tested my changes, checked signatures, checksums,
licences. All looks good.
On Fri, Mar 3, 2023 at 3:33 PM Elad Kalif wrote:
>
> Hey all,
>
> I have just cut the new wave Airflow Providers packages. This email is
> calling a vote on the release, which will last for 72 hours -
Hey everyone,
TL;DR; I would like to ask for a lazy consensus of adding a footer to
our users@ list explaining how to unsubscribe.
There were quite a few users that got confused about unsubscribing
from users@ list. I think there are quite a few reasons why we should
inform the users how they
You submitted a lot of questions that you will not individually get an
answer to individually.
Please consult relevant databases of your choice to get your answers.
The CVE databases out there purpose is to provide all the information
necessary. If every user would ask questions about every
Wonderful :)
On Tue, Feb 28, 2023 at 11:25 PM John Thomas
wrote:
>
> Sounds good! Thanks for the heads up - I'll pull from announce next month :)
>
>
> On Tue, Feb 28, 2023 at 2:55 PM Jed Cunningham
> wrote:
>>
>> Thanks for putting this together John.
>>
>> I'd just like to mention to readers
: Screenshot 2023-02-28 at 22.45.00.png]
On Tue, Feb 28, 2023 at 10:35 PM John Thomas
wrote:
> Generally if there are CVEs sent out on the devlist I'll include them, but
> there weren't any sent out recently. Is there a better source for them?
>
> On Tue, Feb 28, 2023 at 2:33 PM Jarek P
One small proposal for the future: Should we also include the summary of
security vulnerabilities announced and published including credits for
those researchers that help to find them? Airflow has been marked as
"important" OSS software and a number of security reports we get and as a
result we
On Tue, Feb 21, 2023 at 11:23 PM Jarek Potiuk wrote:
>>
>> And to add a little "parallel" - I think Open Lineage integration replacing
>> our "generic lineage" is very similar step to the new "Multi-tenant"-ready
>&g
The vote has passed. We will be moving the executors soon (about the
same time we complete AIP-51)
One step closer to making sure Providers are not referred in the Airflow core.
Voting summary:
8 "+1" binding votes received:
- Jarek Potiuk (binding)
- Ash Berlin-Taylor (binding)
-
Clearly #27758
On Fri, Feb 24, 2023 at 11:17 PM John Thomas
wrote:
> Hi Folks,
>
> It's that time again! Vote for a PR that you think deserves it this month
> - our candidates from the script are as follows:
>
> * [27758] "Enable trigger logging in webserver
>
Cool :). Teamwork :D
On Fri, Feb 24, 2023 at 12:13 AM Jed Cunningham
wrote:
> Here it is: https://github.com/apache/airflow-site/pull/742
>
>
> Vikram
>
>
> On Thu, Feb 23, 2023 at 6:28 AM Jarek Potiuk wrote:
>
>> The temporary fix worked - for now. The < 1.10.15 docs are no more on
>> our pages:
>> https://airflow.apache.org/docs/apache-airflow/stable/index.html.
>> The new provider docs a
her versions of some other docs - I
believe we have no contingency plan and we might be left with
inability to publish new docs, unless we have someone seriously
looking and making the docs building process sustainable.
J.
On Thu, Feb 23, 2023 at 2:19 PM Jarek Potiuk wrote:
>
> I meant < 1.10.1
I meant < 1.10.15 everywhere BTW
On Thu, Feb 23, 2023 at 2:10 PM Jarek Potiuk wrote:
>
> Hello everyone,
>
> We just ran out of space for the Airflow documentation build and our
> documentation stopped being published - with the last provider's
> releases.
>
> The p
Hello everyone,
We just ran out of space for the Airflow documentation build and our
documentation stopped being published - with the last provider's
releases.
The process of building requires all versions of Airflow to be present
when publishing new documentation.
As a stop-gap measure - I
Hello everyone,
The ASF First Contribution campaign launched recently - to gather and
share with others your first contribution experiences/story.
We'd love to see a wide range of people sharing, whether you made your
first commit 10 days ago or 10 years.
Blog post:
cases. and if we want to step-it-up we need to
come up with something better (and Open Lineage happens to be one that has
been developed with Airflow in mind and battle tested).
J.
On Wed, Feb 22, 2023 at 8:16 AM Jarek Potiuk wrote:
> Hey Rafał (Eugene, Michal - and others who are looking),
&g
t; are pieces of metadata <https://openlineage.io/docs/#core-model>each
>>> with their own JsonSchema.
>>> For example a table from a relational database will have a schema facet
>>> when a file in GCS might not.
>>> So I think in Airflow we could have each
fast
> evolution of providers, but given the benefits on the executor side, I vote
> for it.
> From: Jarek Potiuk
> Sent: Tuesday, February 21, 2023 8:45:15 AM
> To: dev@airflow.apache.org
> Subject: [VOTE] Move K8S / Celery (and related) executors to respective
> providers
>
&g
Hello everyone,
This is a call for the vote to make an internal change to move the code of
K8S, Celery and related (LocalKubernetes., CeleryKubernetes etc. ) to
respective providers.
Consider it +1 (binding) from my side.
This has been discussed in
+1 binding. I checked the changes I Implemented are all included,
verified licences, signatures, checksums. All good.
On Sat, Feb 18, 2023 at 10:14 PM Elad Kalif wrote:
>
> Hey all,
>
> I have just cut the new wave Airflow Providers packages. This email is
> calling a vote on the release,
>
And to Kaxil's mail: yep. What you wrote is exactly what I understood
needs to be done.
On Fri, Feb 17, 2023 at 2:40 PM Jarek Potiuk wrote:
>
> > Understood. I like the idea of extensibility and "Airflow as a platform."
> > However, we should make sure that we do not w
t; permissioning model, and you considered replacing FAB?
>
> I believe that the primary motivation for "user management provider" is
> driven by the excitement around getting rid of FAB, which I think we can
> still achieve while including multi-tenancy in the core Airflow. Bot
ning/) version supported
> for 5 years since initial release + 1 patch. And also Postgres Community
> provide the list of currently supported version of Postgres and when latest
> patch plan to release / released for specific major version of Postgres 李
>
>
> Best Wishes
>
Yeah. I think we only made "cloud" exception for K8S version because we
thought it is really something of a deployment environment. And I am still
not 100% convinced we should do it. So yeah - dropping support as soon as
the "owner" of the DB drops it should be fine :)
On Thu, Feb 16, 2023 at
w core". To achieve this, it may be helpful to first
>> outline the perspectives of the Airflow PMCs. Recently, there have been
>> discussions regarding the separation of executors into a separate package,
>> the implementation of pluggable schedulers, and other related to
way to prevent GHA abuse.
>
> Best Regards,
> Pierre
>
> Le lun. 13 févr. 2023 à 21:59, Jarek Potiuk a écrit :
>
>> For others who might also share the same concerns, my ticket where I
>> explain what effects it will have on our project, and in comment I
>>
kflow. It
makes me wonder how other projects are handling their workflow if this
doesn't break them. I can only see this working for a small team who
are all/mostly committers and rarely get outside contributions.`
J.
On Mon, Feb 13, 2023 at 9:26 PM Jarek Potiuk wrote:
>
> Surely. I wi
BTW. I am going to strongly oppose that (ticket is coming)
-- Forwarded message -
From: Jarek Potiuk
Date: Mon, Feb 13, 2023 at 8:55 PM
Subject: Re: [NOTICE] Upcoming global changes to default GitHub
Actions behavior for outside collaborators
To:
Cc:
I will raise a ticket
opriate to make sure coverage
> is at the right level and tests are in the right place.
> I'm looking forward to more discussion on the details.
> Julien
>
> On Sat, Feb 11, 2023 at 11:57 PM Jarek Potiuk wrote:
>>
>> A little side-track., small comment to what Shubh
> proposal here as alternate user management providers. Maybe, this also
> enables us to get rid of the Fab security manager from core Airflow?
>
> Best regards,
> Vikram
>
>
> On Fri, Feb 3, 2023 at 8:22 AM Beck, Vincent
> wrote:
>>
>> Thanks __
>
to correct it.
> Dashboard can be really nice.
>
> 3) There is not much we can do. The next step after triage is to open PR.
> This depends on someone who will pick up the issue.
> We can measure time since creation/last action but also break by reported
> version.
>
>
&g
ng waiting for triage time (script that
> checks open issues with the labels (daily?) and possibly push notification to
> the issue-triage channel in slack or some other channel?)
>
> There are many further improvements we can do. For example setup
> https://github.com/google/triag
mple in compare to Airflow core.
>
> To my it looks like moving executors to providers contains only benefits.
>
> On Wed, Feb 1, 2023 at 11:11 PM Jarek Potiuk wrote:
>>
>> - "evolve K8S executor faster": so far I don't see the provider being
>> released
> maybe we should instead try to pull back just a bit on what we promise
> concerning backcompat.
Yes. Full agreement.
On Fri, Jan 27, 2023 at 8:20 PM Daniel Standish
wrote:
>
> Thinking about this some more.
>
> As an airflow developer, a lot of our backcompat concerns (which takes up a
>
th a new one (for example:
> reported_version:2.0 -> reported_version:2.5) this will bump the issue to the
> latest bug lists.
>
>
> On Sun, Feb 12, 2023 at 5:48 PM Jarek Potiuk wrote:
>>
>> TL;DR; I think we should first solve the issue of improving our
>> "resp
TL;DR; I think we should first solve the issue of improving our
"responsiveness" as committers first. I believe once we solve it, the
stale bot closing issue will be a useful and non-offensive tool.
(Sorry for a loong email, but I have been thinking a lot about it and
I had many observations
A little side-track., small comment to what Shubham wrote
Yeah. I also noticed AIP-47 mentioned - but I considered that
implementation detail. I read that those will be rather regular unit
tests (so not reaching out to external systems as it makes little
sense and we definitely want to make
I do not think we need more time than given by DB providers. I wonder
(and this is more of a guess - because I have no data to back it up)
extra time is not going to be used anyway. But I am not very strong on
that. As long as we have "a" policy and we communicate it clearly, I
am good.
Why do I
+1 binding. Looked at the latest changes, my concerns were alleviated. I
think there are a few implementation details that might need clarifications
during implementation but overall i think it is a good move for the
community.
On Sat, Feb 11, 2023 at 8:42 AM Ash Berlin-Taylor wrote:
>
> +1
>>>>>> and export it to Data Lineage (Data Catalog service) for further
>>>>>> analysis.
>>>>>> https://cloud.google.com/composer/docs/composer-2/lineage-integration
>>>>>>
>>>>>> This feature is as of now in the "
+1 (binding). Tested signatures, checksums, licences.
On Thu, Feb 9, 2023 at 1:18 PM Pankaj Koti
wrote:
> +1 non-binding
>
> Tested the Google cloud RC
> https://pypi.org/project/apache-airflow-providers-google/8.9.0rc1/ and my
> PR https://github.com/apache/airflow/pull/29349 which is part of
+1 (binding). Checked signatures, checksum, licences.
Concur with Elad. We can have 1.8.1 with those fixes.
J.
On Mon, Feb 6, 2023 at 12:07 PM Elad Kalif wrote:
>
> +1 (binding)
> Since the reports by Jules don't indicate regression I see no reason to block
> this release.
> Should release
Added.
On Fri, Feb 3, 2023 at 3:53 PM Beck, Vincent
wrote:
>
> Thank you! https://cwiki.apache.org/confluence/display/~vin100.beck
>
> On 2023-02-02, 5:38 PM, "Jarek Potiuk" wrote:
>
> CAUTION: This email originated from outside of the organization. D
What's your cwiki ID, Vincent (I'll add you without going into details yet)
+1 (binding)
On Thu, Feb 2, 2023 at 1:37 PM Ephraim Anierobi
wrote:
>
> +1 (binding)
>
> On Wed, 1 Feb 2023 at 23:35, Jed Cunningham wrote:
>>
>> +1 (binding)
>>
>> Checked signatures, checksums, licences.
Yep. This is super cool.
This morning a friend of mine - Ismael - Developer Advocate from
Microsoft who I co-chaired the Data Engineering track at the ApacheCon
- reached out to me asking how he can learn more and become a
valuable member of the community.
I hope we can get strong contributions
em in the
> "core" seems sensible & natural to me. Also meaning we should be more careful
> with them. I would like to be educated with more advantages/benefits of
> making such a change before I can share a "+1" confidently here.
>
> I definitely have
ily used, if
> > suddenly all our users
> will start having 10 bigger databases that they have now because we will
> deprecate the values and keep all the history, then we have a big number of
> extra disks that will have to be used. I'd strongly prefer a solution where
> we k
hich is not coming via plugin) - but
we might consider that to enhance a bit security and add another layer
of it. We already have a precedent where hive provider exposes both -
provider entrypoint and plugin entrypoint, and we could do the same
for cncf.kubernetes, and celery. Worth considering for sure
happen (basically when single task
instance does the delete, anti-insert locks held the other mapped
instances of the same task from inserting rendered fields).
It does not change much in the optimisation proposal of mine, other
than we should include map_index in those queries. But I thi
arcus
>
> On Sun, Jan 29, 2023 at 12:11 PM Jarek Potiuk wrote:
>>
>> TL;DR; Generally we are very cautious about adding new "external
>> service" providers to the community and it's highly unlikely we would
>> want Weaviate in, but you are absolutely free (and e
I vote for #27063 too.
On Mon, Jan 30, 2023 at 8:28 PM Pierre Jeambrun wrote:
>
> Hello,
>
> I vote for #27063 :)
>
> Le lun. 30 janv. 2023 à 20:17, John Thomas
> a écrit :
>>
>> It's a new year and a new newsletter! This vote is a bit late because I had
>> to do some work on the script, but
> Should we also create apache-airflow-providers-dask for DaskExecutor?
Absolutely.
On Mon, Jan 30, 2023 at 8:14 PM Andrey Anshin wrote:
>
> Should we also create apache-airflow-providers-dask for DaskExecutor?
>
>
> Best Wishes
> Andrey Anshin
>
>
>
> On
E__MAX_NUM_RENDERED_TI_FIELDS_PER_TASK and tried run backfill
> than rendered templates not written to table (or may be inserted and after
> that immediately deleted), the same is valid for cleanup old tasks.
>
>
> Best Wishes
> Andrey Anshin
>
>
e the experience
> more modular and pluggable, in general.
>
>
>
>
> From: Jarek Potiuk
> Sent: Sunday, January 29, 2023 1:20 AM
> To: dev@airflow.apache.org
> Subject: [EXTERNAL] [DISCUSSION] Move K8S and Celery Executors (and related)
> to respective providers?
&g
TL;DR; Generally we are very cautious about adding new "external
service" providers to the community and it's highly unlikely we would
want Weaviate in, but you are absolutely free (and encouraged) to
release the provider on your own. Even if there is an open-source
engine (like yours), when there
Yep. Agree this is not an efficient query and dynamic task mapping
makes the effect much worse. Generally speaking, selecting "what
should be left" and then deleting stuff where the key is "not in" is
never an efficient way of running an sql query. And the query not
using index at all makes it
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
riter
>>> "feels" the executor, it should respect semver, certainly. But I'm not
>>> sure we need to guarantee backcompat of its internal methods.
>>>
>>> Another real example: Jed right now is trying to rename pod_id to
>>> pod_name, a sensible cleanup. B
601 - 700 of 2965 matches
Mail list logo
