Move to use okhttp4 due to a bug on IPV6 based cluster

[ppatierno]

The current version of fabric8 Kubernetes client is using okhttp3 library which is affected by bug on hostname verification when connecting to the Kubernetes server API in IPV6 based cluster.
The same bug affects even the kubernetes-client Java library: kubernetes-client/java#1289
This issue was fixed in okhttp4 as you can see from this already merged PR:
square/okhttp#5889

We are facing this while using fabric8 in the Strimzi operator. There is a workaround as described here strimzi/strimzi-kafka-operator#4002 but it's just a workaround.
Is there any plan to update the fabric8 client to the okhttp4 library version?

[rohanKanojia]

Isn't okhttp4 based on kotlin? Not sure if it can break any backward compatibility. @manusa @oscerd @iocanel @metacosm WDYT??

[oscerd]

Yes, it is. It's a completely different library from 3.x

[ppatierno]

So what's the solution you envisage? Back porting the fix about IPV6 from okhttp4 to okhttp3 and then updating fabric8? Right now fabric8 is actually bugged with IPV6 clusters due to this problem in okhttp3 :-(

[oscerd]

Bumping to 4.x is something that require effort and time. I'm not sure they will backport the fix on 3.x anyway

[ppatierno]

Well,, that could be a contribution to backport on okhttp3 if they won't do that. Otherwise, you should list this as a well-known bug on fabric8.

[manusa]

Bumping OkHTTP version to 4.x will not only require a lot of work in the client, but some work on the Kubernetes Client Quarkus extension too (I think).

I agree that we should eventually upgrade to 4.x, new issues are bound to happen in the future. But I'm not sure if the timing is right at the moment, since we need to deliver 5.0 ASAP.

Maybe for the time being contributing a backport of the fix to OkHttp 3.x is more cost-effective WDYT?

[metacosm]

Maybe for the time being contributing a backport of the fix to OkHttp 3.x is more cost-effective WDYT?

Are we confident the backport would be accepted, though? Or are we talking about maintaining a 3.x fork until the time when we decide to switch to 4?

[manusa]

My suggestion was just (for now) try to see if the back-port is accepted in the OkHttp project, since it's only a few lines (square/okhttp#5889 - haven't checked branch compatibility though).
Maintaining an OkHttp is not what I was implying. That would probably be a much greater effort than upgrading the dependency in the client.

[yschimke]

OkHttp 4.x is binary backwards compatible with OkHttp 3.x. The only breaking experience would be if you have kotlin clients building as it's not source compatible. Full description here https://square.github.io/okhttp/upgrading_to_okhttp_4/

It is not a whole new library, clients can upgrade and downgrade (and do, like in Retrofit) since the public API is maintained.

3.14.x is no longer maintained, so you should upgrade to 4.x unless you wanted legacy support with 3.12.12 (Java 7, Android < 5). See https://square.github.io/okhttp/security/

[maxandersen]

okhttp drags in kotlin runtime,right ? that brings its own set of challenges.

[yschimke]

I'm not aware of any actual runtime. It uses a kotlin stdlib library, but nothing like a JVM runtime.

https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.4.21-2

This is around 20kb.