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 Akka[1]. Ontop of this classical > > remoting happens to be using netty3 which has known CVE's[2], 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 PR[3] 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 artery[4] > > although the decision that Pekko ultimately makes may influence the > > timeline (hence the reason for this thread). > > > > [1]: https://github.com/akka/akka/issues/31764 > > [2]: https://mvnrepository.com/artifact/io.netty/netty/3.10.6.Final > > [3]: https://github.com/apache/incubator-pekko/pull/643 > > [4]: https://pekko.apache.org/docs/pekko/current/remoting-artery.html > > > > -- > > > > 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 >
