Just chipping in that I don't think we should add Pekko changes in a patch release, because I think the Pekko related changes don't fix a bug.
On Tue, Sep 19, 2023 at 9:06 PM Ferenc Csaky <ferenc.cs...@pm.me.invalid> wrote: > > I think that is totally fine, because any Pekko related changes can only be > added to the first patch release of 1.18 at this point, as there is an RC0 > [1] already so the release process will be initiated soon. > > I am glad the mentioned PR got merged, did not have the chance to review. > > [1] https://lists.apache.org/thread/5x28rp3zct4p603hm4zdwx6kfr101w38 > > > > ------- Original Message ------- > On Monday, September 18th, 2023 at 14:20, Matthew de Detrich > <matthew.dedetr...@aiven.io.INVALID> wrote: > > > > > > > > I think that the end of September is too soon for a Pekko 1.1.x, there are > > still more things > > that we would like to merge before making a release. > > > > Good news is that the PR to migrate to netty4 for classic remoting has been > > merged > > (see https://github.com/apache/incubator-pekko/pull/643). Improvements are > > also > > still be done, so the next minor version release of Pekko (1.1.0) will > > contain these > > changes. > > > > On Wed, Sep 13, 2023 at 11:22 AM Ferenc Csaky ferenc.cs...@pm.me.invalid > > > > wrote: > > > > > The target release date for 1.18 is the end of Sept [1], but I'm not sure > > > everything will come together by then. Maybe it will pushed by a couple > > > days. > > > > > > I'm happy to help out, even making the Flink related changes when we're at > > > that point. > > > > > > [1] https://cwiki.apache.org/confluence/display/FLINK/1.18+Release > > > > > > ------- Original Message ------- > > > On Tuesday, September 12th, 2023 at 17:43, He Pin he...@apache.org > > > wrote: > > > > > > > Hi Ferenc: > > > > What's the ETA of the Flink 1.18? I think we should beable to > > > > collaborate on this，and at work we are using Flink too. > > > > > > > > On 2023/09/12 15:16:11 Ferenc Csaky wrote: > > > > > > > > > Hi Matthew, > > > > > > > > > > Thanks for bringing this up! Cca half a year ago I started to work on > > > > > an Akka Artery migration, there is a draft PR for that 1. It might be > > > > > an > > > > > option to revive that work and point it against Pekko instead. > > > > > Although I > > > > > would highlight FLINK-29281 2 which will replace the whole RPC > > > > > implementation in Flink to a gRPC-based one when it is done. > > > > > > > > > > I am not sure about the progess on the gRPC work, it looks hanging for > > > > > a while now, so I think if there is a chance to replace Netty3 with > > > > > Netty4 > > > > > in Pekko in the short term it would benefit Flink and then we can > > > > > decide if > > > > > it would worth to upgrade to Artery, or how fast the gRPC solution > > > > > can be > > > > > done and then it will not be necessary. > > > > > > > > > > All in all, in the short term I think Flink would benefit to have that > > > > > mentioned PR 3 merged, then the updated Pekko version could be > > > > > included in > > > > > the first 1.18 patch probably to mitigate those pesky Netty3 CVEs > > > > > that are > > > > > carried for a while ASAP. > > > > > > > > > > Cheers, > > > > > Ferenc > > > > > > > > > > 1 https://github.com/apache/flink/pull/22271 > > > > > 2 https://issues.apache.org/jira/browse/FLINK-29281 > > > > > 3 https://github.com/apache/incubator-pekko/pull/643 > > > > > > > > > > ------- Original Message ------- > > > > > On Tuesday, September 12th, 2023 at 10:29, Matthew de Detrich > > > > > matthew.dedetr...@aiven.io.INVALID wrote: > > > > > > > > > > > It's come to my attention that Flink is using Pekko's classical > > > > > > remoting, > > > > > > if this is the case then I would recommend making a response at > > > > > > https://lists.apache.org/thread/19h2wrs2om91g5vhnftv583fo0ddfshm . > > > > > > > > > > > > Quick summary of what is being discussed is what to do with Pekko's > > > > > > classical remoting. Classic remoting is considered deprecated since > > > > > > 2019, > > > > > > an artifact that we inherited from Akka1. Ontop of this classical > > > > > > remoting happens to be using netty3 which has known CVE's2, these > > > > > > CVE's > > > > > > were never fixed in the netty3 series. > > > > > > > > > > > > The question is what should be done given this, i.e. some people in > > > > > > the > > > > > > Pekko community are wanting to drop classical remoting as quickly as > > > > > > possible (i.e. even sooner then what semver allows but this is being > > > > > > discussed) and others are wanting to leave it as it is (even with > > > > > > the > > > > > > CVE's) since we don't want to incentivize and/or create impression > > > > > > that we > > > > > > are officially supporting it. There is also a currently open PR3 > > > > > > which > > > > > > upgrades Pekko's classical remoting's from netty3 to netty4 with the > > > > > > primary motivator being removing said CVE's. > > > > > > > > > > > > My personal position on the matter is that Pekko shouldn't drop > > > > > > classical > > > > > > remoting until 2.0.x (to satisfy semver) while also updating Pekko's > > > > > > classical remoting netty dependency to netty4 so that we are not > > > > > > shipping > > > > > > Pekko with known CVE's (if this gets approved such a change would > > > > > > likely > > > > > > land in Pekko 1.1.0). As is customary, such a decision should be > > > > > > agreed > > > > > > upon broadly in the Pekko community. > > > > > > > > > > > > Note that regardless of this change, it's recommended that a plan > > > > > > should be > > > > > > made at some point by Flink to move from classical remoting to > > > > > > artery4 > > > > > > although the decision that Pekko ultimately makes may influence the > > > > > > timeline (hence the reason for this thread). > > > > > > > > > > > > -- > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > Aiven Deutschland GmbH > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > m: +491603708037 > > > > > > > > > > > > w: aiven.io e: matthew.dedetr...@aiven.io > > > > > > > > -- > > > > Matthew de Detrich > > > > Aiven Deutschland GmbH > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > m: +491603708037 > > > > w: aiven.io e: matthew.dedetr...@aiven.io
