Hi all, Thanks for the feedback. Let me go over the comments/questions:
On the enforcer scope, the rules are deny-by-default rather than an allow-list, and there are two of them: - A global rule bans com.squareup.okhttp3:*:(,4.0) in every module, with a single exemption for test scope (legacy test-only dependency graphs that never reach the distribution). - A flink-dist rule bans com.squareup.okhttp3:* and com.squareup.okio:* outright, at any version. So a maintained OkHttp 4.x is allowed anywhere, but the flink-dist rule is what makes that safe: a module can only keep it if it stays out of the distribution tree, i.e. declared optional/non-transitive and shaded into its own plugin or uber-jar. If someone ever wires one onto the core classpath, the flink-dist build fails. That means no explicit module allow-list: it would need updating whenever a module is added or renamed, and it would restate what the flink-dist rule already enforces. On the failure messages: agreed, and that is already the case, you can see it in the draft PR. And yes, I'll add this to the release notes too. On the runtime version check, that makes sense. I'll add a check when the Fabric8 client is constructed that fails fast when the JVM doesn't have the fix. On the Vert.x topic, thanks for building and testing it. One thing I want to make clear is that the FLIP's rejection of Vert.x is about the adapter Fabric8 actually defaults to, which is Vert.x 4.5 with Netty 4.1. What you're proposing is the non-default kubernetes-httpclient-vertx-5 artifact. So the original FLIP reason is still accurate for the default adapter, but it doesn't address your proposal so I'll update the FLIP for it. But I do think that we then can't claim that Vert.x is Fabric8's default and therefore the most tested, since it's not Vert.x 5 but Vert.x 4.5. I do still think that we shouldn't adopt Vert.x as the default though. That's because the reason for the FLIP is that I wanted to break out of being tied to a specific third party, OkHttp in this case. Vert.x moved from Netty 4.1 to 4.2 in a patch release (5.0.7 -> 5.0.8). So this would mean that moving to Vert.x would pin us to their Netty version, which is a moving target and would just move the link to a different dependency instead of breaking out of the dependency link. I don't think shading gets us out of it either. It would decouple us, but then the Netty alignment stops being a benefit at all, and we'd be adding a third relocated Netty to the distribution: we already ship flink-shaded-netty (4.2.6.Final) and a separately relocated io.netty in flink-rpc-akka (4.2.15). Those two already disagree on version, so we'd be taking on 8 MB and 24 NOTICE entries to buy decoupling that the JDK client gives us with no dependency at all. The JDK adapter gaps are real, but Flink sets none of them and exposes none as Flink options, so I don't think they block us here. I'd also rather depend on what already ships with the JVM than on another third-party stack. Thanks, Martijn Op ma 24 aug 2026 om 21:12 schreef Mate Czagany <[email protected]>: > > Hi Martijn, > > Thank you for this FLIP. I ran into this while upgrading flink-kubernetes > to use Fabric8 7.3.1, and overall I agree with the motivation of removing > OkHttp/Okio. > > For the JDK HTTP client, I agree with Zhe that the JDK version requirement > should be very obvious to the users, but I don't think everyone reads > release notes. My advice would be to add a runtime check to the Kubernetes > client factory that checks the actual JDK version, and fail the application > upon startup if the JDK version is < 11.0.19. > > On the rejected alternative of Vert.x, I think the pulled dependency of > Netty stack could be easily shaded and relocated to > `org.apache.flink.kubernetes.shaded` just like OkHttp/Okio is today. With > the Vert.x 5 adapter (available since Fabric8 7.6), Netty 4.2 is the > upstream-tested pairing and aligns with Flink's own netty-bom (currently > 4.2.15.Final). I tried this locally, and the full flink-kubernetes test > suite passes with the shaded Vert.x adapter. We could alternatively also > pin the exact Netty version Vert.x would use. > The only downside I see would be the increased size of the distribution and > the burden of maintaining the NOTICE files. In my tests the shaded JAR grew > from 17.1 MB to 25.1 MB, with 24 new NOTICE entries (17 of them being > Netty). > Also, since Vert.x is the default HTTP client of Fabric8, it's also the > most tested and used one, thus probably the most stable. > Overall, I think using the Vert.x HTTP client could be a viable alternative. > > Best regards, > Mate > > On Mon, Aug 24, 2026 at 5:24 AM Zhe Wang <[email protected]> wrote: > > > Hi Martijn, > > > > Thanks for writing this FLIP. The direction makes sense to me, especially > > keeping EOL OkHttp out of the shared/core classpath. > > > > One point I think would be useful to make explicit is the boundary of the > > Maven enforcer rules. Since the FLIP allows maintained OkHttp in isolated > > plugin classloaders or standalone connector uber-jars, would the > > implementation use an explicit module allow-list for those exceptions? That > > may make the rule easier to maintain and avoid accidental regressions in > > `flink-dist`. > > > > It would also be helpful if the enforcer failure message points > > contributors to the intended alternatives, e.g. use the JDK HTTP client for > > core/shared classpath code, or keep a maintained OkHttp dependency isolated > > in a plugin/uber-jar when it is genuinely required. > > > > For the compatibility section, I also think the Java 11.0.19 floor is worth > > calling out clearly in release notes, since the behavioral change is > > internal but Kubernetes HA users running older Java 11 updates may > > otherwise miss the WebSocket query-encoding limitation. > > > > Best regards, > > Zhe Wang > > > > > > Robert Metzger <[email protected]> 于2026年8月19日周三 16:45写道： > > > > > Looks like a good security hygiene improvement to me +1 > > > > > > On Wed, Aug 19, 2026 at 10:00 AM Martijn Visser < > > [email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > I'd like to start a discussion on FLIP-607, which proposes migrating > > > > Flink off the end-of-life OkHttp 3.x line and keeping OkHttp off the > > > > core classpath [1] > > > > > > > > Motivation, in short: > > > > > > > > - Flink is pinned on OkHttp 3.14.9. It bundles okio 1.17.2, which > > > > carries CVE-2023-3635 and flags on every scanner/SBOM. > > > > - The pin blocks dependency modernization: the Fabric8 Kubernetes > > > > client can't advance past 7.5, because from Fabric8 7.6.0 the OkHttp > > > > adapter is compiled against the OkHttp 5 API. So flink-kubernetes is > > > > stuck on Fabric8 7.3.1. > > > > > > > > Proposal, in short: > > > > > > > > - Switch flink-kubernetes from kubernetes-httpclient-okhttp to > > > > kubernetes-httpclient-jdk (the built-in java.net.http client) > > > > - Add Maven enforcer rules that forbid OkHttp on the core / flink-dist > > > > classpath and ban EOL OkHttp 3.x globally, while allowing isolated > > > > plugin/uber-jars to keep a maintained OkHttp where genuinely needed. > > > > > > > > One point worth flagging up front for reviewers: the JDK HttpClient > > > > has a documented limitation where WebSocket requests, which is > > > > explained in more detail in the FLIP. That's why the FLIP proposes a > > > > minimum Java 11.0.19. > > > > > > > > Looking forward to your feedback. > > > > > > > > Thanks, > > > > > > > > Martijn > > > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/spaces/FLINK/pages/449282641/FLIP-607+Migrate+Flink+off+end-of-life+OkHttp+keep+it+off+the+core+classpath > > > > > > > > >
