Re: [DISCUSS] simplifying try_number handling

[Amogh Desai]

Looks good to me.

Personally I never ran into any issues with this so far but I agree with
the issues it solves.
Thanks & Regards,
Amogh Desai


On Fri, May 3, 2024 at 2:50 AM Vincent Beck  wrote:

> I am all +1 on this one. This thing gave me headaches when working on
> AIP-44 and I could not understand the difference between the private
> "_try_number" and the public "try_number". Thanks for simplifying it!
>
> This is obviously assuming it does not break anything I am not aware of :)
>
> On 2024/05/02 19:37:32 Daniel Standish wrote:
> > TLDR
> > * changing handling of try_number in
> > https://github.com/apache/airflow/pull/39336
> > * no more private attr
> > * no more getter that changes value based on state of task
> > * no more decrementing
> > * try number now only handled by scheduler
> > * hope that sounds good to all of you
> >
> > For more detail read on...
> >
> > In https://github.com/apache/airflow/pull/39336 I am doing some work to
> > resolve some longstanding pain and frustration caused by try_number.
> >
> > The way we handle try_number has for quite some time been messy and
> > problematic.
> >
> > For example, if you access `ti.try_number` and then change the state to
> or
> > from RUNNING, you will get a different value if you access it again!
> >
> > And the responsibility for managing this number has been distributed
> > throughout the codebase.  For example the task itself always increments
> > when it starts running.  But then if it defers or reschedules itself, it
> > decrements it back down so that when it runs again and naively
> increments,
> > then it will be right again.
> >
> > Recently more issues have become visible as I have worked with AIP-44
> > because for example pydantic does not like private attrs and it's just
> > awkward to know *what value to use* when serializing it when the TI will
> > give you a different answer depending on the state of the task!
> >
> > And there's yet another edge case being solved in this community PR
> > .
> >  And then when we start looking at try history and AIP-64, it also
> forces a
> > look at this.
> >
> > So it all sounds bad and indeed it is bad but I think I have a solution.
> >
> > What I do is, just have the scheduler increment try_number at the moment
> > when it schedules the task.  It alone will have the responsibility for
> > incrementing try_number.  And no where will it ever be decremented.  It
> > will not be incremented when resuming after deferral or reschedule.  And
> > that's about all there is to it.
> >
> > I've tested it out and it works.  But I'm working through many test
> > failures that need to be resolved (there's lots of asserts re
> try_number).
> >
> > One small thing I just want to point out is that if a user were
> previously
> > to be doing `task.run()` sort of manually without the task having been
> > scheduled by the scheduler, well now their try_number won't be
> > automatically incremented.  Same if they just do `airflow tasks run` --
> > because now the responsibility is going to be solely with the scheduler.
> > But airflow was never designed to assume that tasks will be run without
> > having been scheduled, so I do not think that counts as a breaking
> change.
> > So I don't think that's a blocker for this.
> >
> > Thanks for the consideration.  Let me know if you have any concerns.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> For additional commands, e-mail: dev-h...@airflow.apache.org
>
>

Re: [VOTE] Release Airflow 2.9.1 from 2.9.1rc2

[Amogh Desai]

+1 non binding

Performed the same tests as RC1 and found no issues.
Installed the RC, ran a few DAGs from my tests, and random clicks on UI.

Thanks & Regards,
Amogh Desai


On Fri, May 3, 2024 at 1:03 AM Ephraim Anierobi 
wrote:

> Hey fellow Airflowers,
>
> I have cut Airflow 2.9.1rc2. This email is calling a vote on the release,
> which will last at least 30 hours, from Thursday, May 2, 2024 at 07:0 pm
> UTC
> until Saturday, May 4, 2024, at 01:30 am UTC
> <
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=8=20240504T0130=1440
> >,
> and until 3 binding +1 votes have been received.
>
> The status of testing of the release is kept at
> https://github.com/apache/airflow/issues/39326
>
> Consider this my (binding) +1.
>
> Airflow 2.9.1rc2 is available at:
> https://dist.apache.org/repos/dist/dev/airflow/2.9.1rc2/
>
> *apache-airflow-2.9.1-source.tar.gz* is a source release that comes with
> INSTALL instructions.
> *apache-airflow-2.9.1.tar.gz* is the binary Python "sdist" release.
> *apache_airflow-2.9.1-py3-none-any.whl* is the binary Python wheel "binary"
> release.
>
> Public keys are available at:
> https://dist.apache.org/repos/dist/release/airflow/KEYS
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Only votes from PMC members are binding, but all members of the community
> are encouraged to test the release and vote with "(non-binding)".
>
> The test procedure for PMC members is described in:
>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members
>
> The test procedure for contributors and members of the community who would
> like to test this RC is described in:
>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors
>
>
> Please note that the version number excludes the `rcX` string, so it's now
> simply 2.9.1. This will allow us to rename the artifact without modifying
> the artifact checksums when we actually release.
>
> Release Notes:
> https://github.com/apache/airflow/blob/2.9.1rc2/RELEASE_NOTES.rst
>
> For information on what goes into a release please see:
>
> https://github.com/apache/airflow/blob/main/dev/WHAT_GOES_INTO_THE_NEXT_RELEASE.md
>
> Changes since 2.9.0rc1:
>
> *Bugs*:
> Update trigger kwargs migration to specify existing_nullable ( #39361,
> #39374)
>
> Cheers,
> Ephraim
>

Re: [DISCUSS] simplifying try_number handling

[Vincent Beck]

I am all +1 on this one. This thing gave me headaches when working on AIP-44 
and I could not understand the difference between the private "_try_number" and 
the public "try_number". Thanks for simplifying it!

This is obviously assuming it does not break anything I am not aware of :)

On 2024/05/02 19:37:32 Daniel Standish wrote:
> TLDR
> * changing handling of try_number in
> https://github.com/apache/airflow/pull/39336
> * no more private attr
> * no more getter that changes value based on state of task
> * no more decrementing
> * try number now only handled by scheduler
> * hope that sounds good to all of you
> 
> For more detail read on...
> 
> In https://github.com/apache/airflow/pull/39336 I am doing some work to
> resolve some longstanding pain and frustration caused by try_number.
> 
> The way we handle try_number has for quite some time been messy and
> problematic.
> 
> For example, if you access `ti.try_number` and then change the state to or
> from RUNNING, you will get a different value if you access it again!
> 
> And the responsibility for managing this number has been distributed
> throughout the codebase.  For example the task itself always increments
> when it starts running.  But then if it defers or reschedules itself, it
> decrements it back down so that when it runs again and naively increments,
> then it will be right again.
> 
> Recently more issues have become visible as I have worked with AIP-44
> because for example pydantic does not like private attrs and it's just
> awkward to know *what value to use* when serializing it when the TI will
> give you a different answer depending on the state of the task!
> 
> And there's yet another edge case being solved in this community PR
> .
>  And then when we start looking at try history and AIP-64, it also forces a
> look at this.
> 
> So it all sounds bad and indeed it is bad but I think I have a solution.
> 
> What I do is, just have the scheduler increment try_number at the moment
> when it schedules the task.  It alone will have the responsibility for
> incrementing try_number.  And no where will it ever be decremented.  It
> will not be incremented when resuming after deferral or reschedule.  And
> that's about all there is to it.
> 
> I've tested it out and it works.  But I'm working through many test
> failures that need to be resolved (there's lots of asserts re try_number).
> 
> One small thing I just want to point out is that if a user were previously
> to be doing `task.run()` sort of manually without the task having been
> scheduled by the scheduler, well now their try_number won't be
> automatically incremented.  Same if they just do `airflow tasks run` --
> because now the responsibility is going to be solely with the scheduler.
> But airflow was never designed to assume that tasks will be run without
> having been scheduled, so I do not think that counts as a breaking change.
> So I don't think that's a blocker for this.
> 
> Thanks for the consideration.  Let me know if you have any concerns.
> 

-
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org

[ANNOUNCE] Apache Airflow Python Client 2.9.0 Released

[Jed Cunningham]

Dear Airflow community,

I'm happy to announce that Apache Airflow Python Client 2.9.0 was just
released.

We made this version available on PyPI for convenience:
`pip install apache-airflow-client`
https://pypi.org/project/apache-airflow-client/2.9.0/

The documentation is available at:
https://github.com/apache/airflow-client-python/

Find the changelog here for more details:
https://github.com/apache/airflow-client-python/blob/main/CHANGELOG.md

Thanks,
Jed

[DISCUSS] simplifying try_number handling

[Daniel Standish]

TLDR
* changing handling of try_number in
https://github.com/apache/airflow/pull/39336
* no more private attr
* no more getter that changes value based on state of task
* no more decrementing
* try number now only handled by scheduler
* hope that sounds good to all of you

For more detail read on...

In https://github.com/apache/airflow/pull/39336 I am doing some work to
resolve some longstanding pain and frustration caused by try_number.

The way we handle try_number has for quite some time been messy and
problematic.

For example, if you access `ti.try_number` and then change the state to or
from RUNNING, you will get a different value if you access it again!

And the responsibility for managing this number has been distributed
throughout the codebase.  For example the task itself always increments
when it starts running.  But then if it defers or reschedules itself, it
decrements it back down so that when it runs again and naively increments,
then it will be right again.

Recently more issues have become visible as I have worked with AIP-44
because for example pydantic does not like private attrs and it's just
awkward to know *what value to use* when serializing it when the TI will
give you a different answer depending on the state of the task!

And there's yet another edge case being solved in this community PR
.
 And then when we start looking at try history and AIP-64, it also forces a
look at this.

So it all sounds bad and indeed it is bad but I think I have a solution.

What I do is, just have the scheduler increment try_number at the moment
when it schedules the task.  It alone will have the responsibility for
incrementing try_number.  And no where will it ever be decremented.  It
will not be incremented when resuming after deferral or reschedule.  And
that's about all there is to it.

I've tested it out and it works.  But I'm working through many test
failures that need to be resolved (there's lots of asserts re try_number).

One small thing I just want to point out is that if a user were previously
to be doing `task.run()` sort of manually without the task having been
scheduled by the scheduler, well now their try_number won't be
automatically incremented.  Same if they just do `airflow tasks run` --
because now the responsibility is going to be solely with the scheduler.
But airflow was never designed to assume that tasks will be run without
having been scheduled, so I do not think that counts as a breaking change.
So I don't think that's a blocker for this.

Thanks for the consideration.  Let me know if you have any concerns.

[VOTE] Release Airflow 2.9.1 from 2.9.1rc2

[Ephraim Anierobi]

Hey fellow Airflowers,

I have cut Airflow 2.9.1rc2. This email is calling a vote on the release,
which will last at least 30 hours, from Thursday, May 2, 2024 at 07:0 pm UTC
until Saturday, May 4, 2024, at 01:30 am UTC
,
and until 3 binding +1 votes have been received.

The status of testing of the release is kept at
https://github.com/apache/airflow/issues/39326

Consider this my (binding) +1.

Airflow 2.9.1rc2 is available at:
https://dist.apache.org/repos/dist/dev/airflow/2.9.1rc2/

*apache-airflow-2.9.1-source.tar.gz* is a source release that comes with
INSTALL instructions.
*apache-airflow-2.9.1.tar.gz* is the binary Python "sdist" release.
*apache_airflow-2.9.1-py3-none-any.whl* is the binary Python wheel "binary"
release.

Public keys are available at:
https://dist.apache.org/repos/dist/release/airflow/KEYS

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but all members of the community
are encouraged to test the release and vote with "(non-binding)".

The test procedure for PMC members is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members

The test procedure for contributors and members of the community who would
like to test this RC is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors


Please note that the version number excludes the `rcX` string, so it's now
simply 2.9.1. This will allow us to rename the artifact without modifying
the artifact checksums when we actually release.

Release Notes:
https://github.com/apache/airflow/blob/2.9.1rc2/RELEASE_NOTES.rst

For information on what goes into a release please see:
https://github.com/apache/airflow/blob/main/dev/WHAT_GOES_INTO_THE_NEXT_RELEASE.md

Changes since 2.9.0rc1:

*Bugs*:
Update trigger kwargs migration to specify existing_nullable ( #39361,
#39374)

Cheers,
Ephraim

[RESULT][VOTE] Release Apache Airflow Python Client 2.9.0 from 2.9.0rc1

[Jed Cunningham]

Hello,

Apache Airflow Python Client 2.9.0 (based on RC1) has been accepted.

4 "+1" binding votes received:
- Jed Cunningham
- Jarek Potiuk
- Kaxil Naik
- Hussein Awala

2 "+1" non-binding votes received:

- Pankaj Koti
- Amogh Desai

Vote thread:
https://lists.apache.org/thread/okybvk22mzzskflz8vbkvrd07cgj38gw

I'll continue with the release process, and the release announcement will
follow shortly.

Thanks,
Jed

Re: [VOTE] Release Airflow 2.9.1 from 2.9.1rc1

[Ephraim Anierobi]

Hey fellow Airflowers,

A  bug was found in rc1 that'll necessitate an rc2. I'm canceling this vote
and will create 2.9.1rc2 soon.

- Ephraim

On Thu, 2 May 2024 at 06:01, Amogh Desai  wrote:

> +1 non binding
>
> Did a general testing by installing the RC, ran a few DAGs, performed some
> random clicks on the UI, things seem to be working as expected.
>
> Thanks & Regards,
> Amogh Desai
>
>
> On Wed, May 1, 2024 at 10:32 PM Scheffler Jens (XC-AS/EAE-ADA-T)
>  wrote:
>
> > +1 (non binding) - tested 2.9.1rc1 and works great, especially the UI
> > glitches are removed.
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Jens Scheffler
> >
> > Alliance: Enabler - Tech Lead (XC-AS/EAE-ADA-T)
> > Robert Bosch GmbH | Hessbruehlstraße 21 | 70565 Stuttgart-Vaihingen |
> > GERMANY | http://www.bosch.com/
> > Tel. +49 711 811-91508 | Mobil +49 160 90417410 |
> > jens.scheff...@de.bosch.com
> >
> > Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> > Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer;
> > Geschäftsführung: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus
> > Forschner,
> > Stefan Grosch, Dr. Markus Heyn, Dr. Frank Meyer, Dr. Tanja Rückert
> >
> > -Original Message-
> > From: Ephraim Anierobi 
> > Sent: Tuesday, April 30, 2024 1:04 PM
> > To: dev@airflow.apache.org
> > Subject: [VOTE] Release Airflow 2.9.1 from 2.9.1rc1
> >
> > Hey fellow Airflowers,
> >
> > I have cut Airflow 2.9.1rc1. This email is calling a vote on the release,
> > which will last at least 72 hours, from Tuesday, April 30, 2024 at 11:00
> am
> > UTC until Friday, May 3, 2024, at 11:00 am UTC <
> >
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=8=20240503T1100=1440
> > >,
> > and until 3 binding +1 votes have been received.
> >
> > The status of testing of the release is kept at
> > https://github.com/apache/airflow/issues/39326
> >
> > Consider this my (binding) +1.
> >
> > Airflow 2.9.1rc1 is available at:
> > https://dist.apache.org/repos/dist/dev/airflow/2.9.1rc1/
> >
> > *apache-airflow-2.9.1-source.tar.gz* is a source release that comes with
> > INSTALL instructions.
> > *apache-airflow-2.9.1.tar.gz* is the binary Python "sdist" release.
> > *apache_airflow-2.9.1-py3-none-any.whl* is the binary Python wheel
> "binary"
> > release.
> >
> > Public keys are available at:
> > https://dist.apache.org/repos/dist/release/airflow/KEYS
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Only votes from PMC members are binding, but all members of the community
> > are encouraged to test the release and vote with "(non-binding)".
> >
> > The test procedure for PMC members is described in:
> >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md/#verify-the-release-candidate-by-pmc-members
> >
> > The test procedure for contributors and members of the community who
> would
> > like to test this RC is described in:
> >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md/#verify-the-release-candidate-by-contributors
> >
> >
> > Please note that the version number excludes the `rcX` string, so it's
> now
> > simply 2.9.1. This will allow us to rename the artifact without modifying
> > the artifact checksums when we actually release.
> >
> > Release Notes:
> > https://github.com/apache/airflow/blob/2.9.1rc1/RELEASE_NOTES.rst
> >
> > For information on what goes into a release please see:
> >
> >
> https://github.com/apache/airflow/blob/main/dev/WHAT_GOES_INTO_THE_NEXT_RELEASE.md
> >
> > Changes since 2.9.0:
> >
> > *Significant Changes*
> >
> > *Stackdriver logging bugfix requires Google provider ``10.17.0`` or later
> > (#38071)*
> >
> > If you use Stackdriver logging, you must use Google provider version
> > ``10.17.0`` or later. Airflow ``2.9.1`` now passes ``gcp_log_name`` to
> the
> > ``StackdriverTaskHandler`` instead of ``name``, and this will fail on
> > earlier provider versions.
> >
> > This fixes a bug where the log name configured in ``[logging]
> > remove_base_log_folder`` was overridden when Airflow configured logging,
> > resulting in task logs going to the wrong destination.
> >
> > *Bug Fixes*
> > - Make task log messages include run_id (#39280)
> > - Copy menu_item ``href`` for nav bar (#39282)
> > - Fix trigger kwarg encryption migration (#39246)
> > - Add workaround for datetime-local input in ``firefox`` (#39261)
> > - Add Grid button to Task Instance view (#39223)
> > - Get served logs when remote or executor logs not available for
> > non-running task try (#39177)
> > - Fixed side effect of menu filtering causing disappearing menus (#39229)
> > - Use grid view for Task Instance's ``log_url`` (#39183)
> > - Improve task filtering ``UX`` (#39119)
> > - Improve rendered_template ``ux`` in react dag page (#39122)
> > - Graph view improvements (#38940)
> > - Check that the dataset<>task exists before trying to render graph
> > (#39069)
> > - 

Re: [VOTE] Airflow Providers prepared on May 01, 2024

[Elad Kalif]

I will exclude pinecone from this release.
Please continue voting excluding pinecone provider

On Thu, May 2, 2024 at 3:19 PM Ankit Chaurasia  wrote:

> -1 non-binding for Pinecone: 2.0.0rc1
>
> There is an issue with Pinecone: 2.0.0rc1 with the system test. This bug is
> introduced as part of the following PR Pinecone provider support for
> pinecone-client>=3 (#37307): @rawwar
> 
>
> PR #39365  should fix it.
>
> *Ankit Chaurasia*
> HomePage  |  LinkedIn
> 
>
>
>
>
>
>
> On Thu, May 2, 2024 at 10:47 AM Amogh Desai 
> wrote:
>
> > +1 non binding
> >
> > Installed the tarball and ran some example DAGs for hive and cncf
> provider,
> > works as expected.
> >
> > Thanks & Regards,
> > Amogh Desai
> >
> >
> > On Wed, May 1, 2024 at 10:49 PM Vincent Beck 
> wrote:
> >
> > > +1 non binding. All AWS system tests are working successfully against
> > > apache-airflow-providers-amazon==8.21.0rc1. You can see the results
> here:
> > >
> >
> https://aws-mwaa.github.io/#/open-source/system-tests/version/fe4605a10e26f1b8a180979ba5765d1cb7fb0111_8.21.0rc1.html
> > .
> > > The only failure (example_bedrock) is a known issue in the test itself
> > and
> > > is currently being worked on.
> > >
> > > On 2024/05/01 13:03:07 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 - which means that it will end on May
> 04,
> > > 2024
> > > > 13:00 PM UTC and until 3 binding +1 votes have been received.
> > > >
> > > >
> > > > Consider this my (binding) +1.
> > > >
> > > > *Note some of the providers are rc2 and some rc1.*
> > > >
> > > > Airflow Providers are available at:
> > > > https://dist.apache.org/repos/dist/dev/airflow/providers/
> > > >
> > > > *apache-airflow-providers--*.tar.gz* are the binary
> > > >  Python "sdist" release - they are also official "sources" for the
> > > provider
> > > > packages.
> > > >
> > > > *apache_airflow_providers_-*.whl are the binary
> > > >  Python "wheel" release.
> > > >
> > > > The test procedure for PMC members is described in
> > > >
> > >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-candidate-by-pmc-members
> > > >
> > > > The test procedure for and Contributors who would like to test this
> RC
> > is
> > > > described in:
> > > >
> > >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-candidate-by-contributors
> > > >
> > > >
> > > > Public keys are available at:
> > > > https://dist.apache.org/repos/dist/release/airflow/KEYS
> > > >
> > > > Please vote accordingly:
> > > >
> > > > [ ] +1 approve
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove with the reason
> > > >
> > > > Only votes from PMC members are binding, but members of the community
> > are
> > > > encouraged to test the release and vote with "(non-binding)".
> > > >
> > > > Please note that the version number excludes the 'rcX' string.
> > > > This will allow us to rename the artifact without modifying
> > > > the artifact checksums when we actually release.
> > > >
> > > > The status of testing the providers by the community is kept here:
> > > > https://github.com/apache/airflow/issues/39346
> > > >
> > > > The issue is also the easiest way to see important PRs included in
> the
> > RC
> > > > candidates.
> > > > Detailed changelog for the providers will be published in the
> > > documentation
> > > > after the
> > > > RC candidates are released.
> > > >
> > > > You can find the RC packages in PyPI following these links:
> > > >
> > > > https://pypi.org/project/apache-airflow-providers-airbyte/3.8.0rc1/
> > > > https://pypi.org/project/apache-airflow-providers-alibaba/2.8.0rc1/
> > > > https://pypi.org/project/apache-airflow-providers-amazon/8.21.0rc1/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-beam/5.7.0rc1/
> > > >
> > >
> >
> https://pypi.org/project/apache-airflow-providers-apache-cassandra/3.5.0rc1/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-drill/2.7.0rc1/
> > > >
> > >
> >
> https://pypi.org/project/apache-airflow-providers-apache-druid/3.10.0rc1/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-flink/1.4.0rc1/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-hdfs/4.4.0rc2/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-hive/8.1.0rc1/
> > > >
> > >
> >
> https://pypi.org/project/apache-airflow-providers-apache-impala/1.4.0rc1/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-kafka/1.4.0rc2/
> > > >
> > https://pypi.org/project/apache-airflow-providers-apache-kylin/3.6.0rc2/
> > > >
> > 

Re: [VOTE] Airflow Providers prepared on May 01, 2024

[Ankit Chaurasia]

-1 non-binding for Pinecone: 2.0.0rc1

There is an issue with Pinecone: 2.0.0rc1 with the system test. This bug is
introduced as part of the following PR Pinecone provider support for
pinecone-client>=3 (#37307): @rawwar


PR #39365  should fix it.

*Ankit Chaurasia*
HomePage  |  LinkedIn







On Thu, May 2, 2024 at 10:47 AM Amogh Desai 
wrote:

> +1 non binding
>
> Installed the tarball and ran some example DAGs for hive and cncf provider,
> works as expected.
>
> Thanks & Regards,
> Amogh Desai
>
>
> On Wed, May 1, 2024 at 10:49 PM Vincent Beck  wrote:
>
> > +1 non binding. All AWS system tests are working successfully against
> > apache-airflow-providers-amazon==8.21.0rc1. You can see the results here:
> >
> https://aws-mwaa.github.io/#/open-source/system-tests/version/fe4605a10e26f1b8a180979ba5765d1cb7fb0111_8.21.0rc1.html
> .
> > The only failure (example_bedrock) is a known issue in the test itself
> and
> > is currently being worked on.
> >
> > On 2024/05/01 13:03:07 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 - which means that it will end on May 04,
> > 2024
> > > 13:00 PM UTC and until 3 binding +1 votes have been received.
> > >
> > >
> > > Consider this my (binding) +1.
> > >
> > > *Note some of the providers are rc2 and some rc1.*
> > >
> > > Airflow Providers are available at:
> > > https://dist.apache.org/repos/dist/dev/airflow/providers/
> > >
> > > *apache-airflow-providers--*.tar.gz* are the binary
> > >  Python "sdist" release - they are also official "sources" for the
> > provider
> > > packages.
> > >
> > > *apache_airflow_providers_-*.whl are the binary
> > >  Python "wheel" release.
> > >
> > > The test procedure for PMC members is described in
> > >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-candidate-by-pmc-members
> > >
> > > The test procedure for and Contributors who would like to test this RC
> is
> > > described in:
> > >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-candidate-by-contributors
> > >
> > >
> > > Public keys are available at:
> > > https://dist.apache.org/repos/dist/release/airflow/KEYS
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Only votes from PMC members are binding, but members of the community
> are
> > > encouraged to test the release and vote with "(non-binding)".
> > >
> > > Please note that the version number excludes the 'rcX' string.
> > > This will allow us to rename the artifact without modifying
> > > the artifact checksums when we actually release.
> > >
> > > The status of testing the providers by the community is kept here:
> > > https://github.com/apache/airflow/issues/39346
> > >
> > > The issue is also the easiest way to see important PRs included in the
> RC
> > > candidates.
> > > Detailed changelog for the providers will be published in the
> > documentation
> > > after the
> > > RC candidates are released.
> > >
> > > You can find the RC packages in PyPI following these links:
> > >
> > > https://pypi.org/project/apache-airflow-providers-airbyte/3.8.0rc1/
> > > https://pypi.org/project/apache-airflow-providers-alibaba/2.8.0rc1/
> > > https://pypi.org/project/apache-airflow-providers-amazon/8.21.0rc1/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-beam/5.7.0rc1/
> > >
> >
> https://pypi.org/project/apache-airflow-providers-apache-cassandra/3.5.0rc1/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-drill/2.7.0rc1/
> > >
> >
> https://pypi.org/project/apache-airflow-providers-apache-druid/3.10.0rc1/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-flink/1.4.0rc1/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-hdfs/4.4.0rc2/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-hive/8.1.0rc1/
> > >
> >
> https://pypi.org/project/apache-airflow-providers-apache-impala/1.4.0rc1/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-kafka/1.4.0rc2/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-kylin/3.6.0rc2/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-livy/3.8.0rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-pig/4.4.0rc2/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-pinot/4.4.0rc2/
> > >
> https://pypi.org/project/apache-airflow-providers-apache-spark/4.8.0rc2/
> > > https://pypi.org/project/apache-airflow-providers-apprise/1.3.0rc2/
> > > https://pypi.org/project/apache-airflow-providers-arangodb/2.5.0rc1/
> > >