Thanks, The PR[1] is ready now, would you like to help review it, thanks. 1. https://github.com/apache/incubator-pekko/pull/643
On 2023/09/13 09:20:48 Ferenc Csaky 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 >
