Upgrade to okhttp3 version 5

[klopfdreh]

Is your enhancement related to a problem? Please describe

kubernetes-client should be upgrade to okhttp3 version 5.3.2

as it otherwise collides with the version used in https://github.com/open-telemetry/opentelemetry-java/

Describe the solution you'd like

Please update to okhttp3 version 5.3.2

Reference:

https://github.com/fabric8io/kubernetes-client/blob/main/pom.xml#L90

Describe alternatives you've considered

There is no alternative as when both libraries are in the class path there are method not found and / or class not found exceptions.

Additional context

No response

[klopfdreh]

Here is a workaround as it seems that all implementation provided in kubernetes-httpclient-okhttp are compatible to 5.3.2.

        <!-- kubernetes dependencies -->
        <!-- https://github.com/eclipse-vertx/vert.x/issues/5484 -->
        <!-- https://github.com/fabric8io/kubernetes-client/issues/6868#issuecomment-2642678040 -->
        <dependency>
            <groupId>io.fabric8</groupId>
            <artifactId>kubernetes-client</artifactId>
            <exclusions>
                <!-- exclude kubernetes-httpclient-vertx because of native images -->
                <exclusion>
                    <groupId>io.fabric8</groupId>
                    <artifactId>kubernetes-httpclient-vertx</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>io.fabric8</groupId>
            <artifactId>kubernetes-httpclient-okhttp</artifactId>
            <exclusions>
                <!--  Exclude okhttp3 as it is provided in version 4.x which collides with opentelemetry -->
                <exclusion>
                    <artifactId>logging-interceptor</artifactId>
                    <groupId>com.squareup.okhttp3</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>okhttp</artifactId>
                    <groupId>com.squareup.okhttp3</groupId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <artifactId>logging-interceptor</artifactId>
            <groupId>com.squareup.okhttp3</groupId>
            <version>5.3.2</version>
        </dependency>
        <dependency>
            <artifactId>okhttp</artifactId>
            <groupId>com.squareup.okhttp3</groupId>
            <version>5.3.2</version>
        </dependency>
        <dependency>
            <groupId>io.fabric8</groupId>
            <artifactId>openshift-client</artifactId>
        </dependency>

[manusa]

Let's examine if we want to bump the client to v5 or provide it as a different client implementation.
As per your provided analysis, bumping the version should be just fine. Will come back to you in the PR (thx for taking care of it).

Relates to:

• upgrade okhttp 4.12 #6109
• Move to use okhttp4 due to a bug on IPV6 based cluster #2632

[klopfdreh]

Hey @manusa - thanks a lot for the response - the reason I updated the client module and not introduced a new one is because I saw that for each integration there is one module e.g. jetty / jdk / okhttp3 / vertx, but not more modules per major release e.g. okhttp3_v4 / okhttp3_v5.

Also there is no API change that affected the module of client okhttp3.

I am interested in why you consider to create a different client module for that - can you explain it to me?

[manusa]

the reason I updated the client module and not introduced a new one is because I saw that for each integration there is one module

#7184

😅 there are, but not yet merged (working on it)

I am interested in why you consider to create a different client module for that - can you explain it to me?

For OkHttp, it might not be necessary. AFAIR v4 was binary compatible (or sort of) with v3 and users should have no problem bumping the dependency.
I recently used OkHttp5 for another project and I think the situation hasn't changed, users should be able to switch to OkHttp5 without problems (based on your PR changes that should be the case).

For modules where the upgrade is not so straightforward (see vert.x), we want to provide a separate client implementation to ease the migration. This would be the main purpose.

So to summarize, your PR should be fine and go in just as is (we might want to reconsider this as a feat and maybe add some "breaking changes" note in the changelog to make sure users are aware of the major version change)

[klopfdreh]

😅 there are, but not yet merged (working on it)

Oh my bad - didn’t saw the opened PR.

Apache HTTP Client also did a major shift in usage and there the team went for different package names.

I understand why you evaluate it based on the effort needed during a major version upgrade.

Thank a lot for the explanation! 👍