Move to Vert.x HTTP Client

[gastaldi]

Okhttp is no longer a single JAR and 4.x brings transitive dependencies (the kotlin-stdlib which is 1.5Mb).

There is a discussion about adopting Vert.x as the HTTP client here: https://github.com/quarkusio/quarkus/pull/14662

Fixing this issue needs to also fix the problem reported in https://github.com/fabric8io/kubernetes-client/issues/2632

[jorsol]

Ideally, (but this might bring its own challenges) is to be agnostic of the HTTP Client, and make it pluggable, if users want to use Apache HttpClient 5, or OkHttp 4, or Vert.x HTTP Client, or what I consider a nice zero-dependency: Java 11 HttpClient, would be great, this way Kubernetes-Client will not force a particular dependency.

And yes, this is probably a more invasive change and is subject to more challenges that just stick to one dependency.

[gastaldi]

@jorsol I think that's also possible, considering an abstraction layer is introduced in the HTTP operations part.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[shawkins]

Julien Viet provided an outline of a client support at https://github.com/shawkins/httpclient/pull/1

There is still a fair amount of work to be done.

[shawkins]

@metacosm @vietj @manusa I've picked this up again at https://github.com/fabric8io/kubernetes-client/tree/vertx-client

There are plenty of unsupported things and todos left. I'll take another couple of passes over it to see if I can get the consume and interceptor logic roughed in - then reach out for anything that isn't easy to move forward.

It's not yet used, but later I'm guessing we'll need to use the abstract builder to support creating derived clients - the only really tricky thing there is the modification of the interceptors that we do for the openshift logic. It switches to specific token interceptor, or removes itself when making the refresh call.

[manusa]

@metacosm @vietj @manusa I've picked this up again at https://github.com/fabric8io/kubernetes-client/tree/vertx-client

Thx!

There are plenty of unsupported things and todos left. I'll take another couple of passes over it to see if I can get the consume and interceptor logic roughed in - then reach out for anything that isn't easy to move forward.

Oh, I was under the impression that https://github.com/shawkins/httpclient/pull/1 has the main hiccups addressed and would be possible after #3971 :disappointed:

[shawkins]

@vietj @metacosm I've made a few more changes, such as bringing in the WebClient dependency for interceptor handling. However it will speed things along if I can get some help with the following (marked with a TODO or unsupported exception in the code):

• Confirmation that some of the config properties are not needed / meaningful - including should a general readTimeout be enforced
• A few more config property implementations, such as SSL support, proxy support (seems like user / password may need to be passed separately),
• Interceptor implementation - probably needs to be added per request to support the derived client modification of interceptors. Also needs to be applied to WebSocket requests.
• Mapping to and from InputStream (send as a body, or receive) - is there another library for this already for compatibility with ReadStream/WriteStream?
• Mapping to consumes methods

[shawkins]

Updated the pr a little bit more: https://github.com/fabric8io/kubernetes-client/tree/vertx-client - updated to master and pulled in a couple of prospective changes, such as removing the need for a sendAsync implementation (which addresses the InputStream/Reader line item above - except for when it's used in a POST).

However it's still pretty far from functional. Wiring in interceptors before a websocket invocation is straight-forward. Afterwards looks problematic - I think the only thing we can do is add exception handling to the future and try to differentiate between a response issue, and a more general IO problem.

We also aren't able to use the AbstractXXX test classes in the vertx module due to the conflicting junit versions.

[manusa]

Work on the Vert.x HttpClient implementation is also being tracked at https://github.com/quarkusio/quarkus/issues/29520

[manusa]

Quarkus has finally migrated to use the Vert.x HttpClient implementation. Closing this issue as complete.

As we gather feedback from the Vert.x implementation, in the future, we should consider to make Vert.x the default.