Hi all, Unless there are more discussion comments, I'd like to start a vote at the end of next week.
Best regards, Martijn Op di 25 aug 2026 om 15:59 schreef Martijn Visser <[email protected]>: > > 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 > > > > > > > > > > > >
