Disable Vertx DNS resolver when deploying to kubernetes

[geoand]

Fixes: #30951

P.S. This is the same fix we have used in other extensions (like Spring Cloud Config Client) that need a Vertx client based on a Vertx instance (that differs from the managed one Quarkus provides at runtime)

[Sgitario]

These changes do work, but only when the quarkus-kubernetes-client extension is present.
If we're using only the quarkus-openshift extension, it keeps failing.

[geoand]

Very interesting!

I'll have a closer look

[geoand]

@manusa can you remind me what the rationale was for putting QuarkusHttpClientFactory in quarkus-kubernetes-client instead of quarkus-kubernetes-client-internal?

It seems to me like the later would make more sense as it would mean that it's always picked up.

[geoand]

I pushed a commit which makes the move I mentione above and it seems to work.

@manusa @Sgitario can you guys confirm that the client behaves as expected now (for both deployment and runtime code)?

[manusa]

@manusa can you remind me what the rationale was for putting QuarkusHttpClientFactory in quarkus-kubernetes-client instead of quarkus-kubernetes-client-internal?

It seems to me like the later would make more sense as it would mean that it's always picked up.

This was based on our private conversation, but there we didn't discuss about internal vs. non-internal. So probably I decided upon my understanding.

I'm not sure about what the -internal module is used for (I don't recall seeing it in the guidelines). I guess my rationale is/was that users should be aware of the SPI-based HttpClient factory that Quarkus provides hence making it public (pure semantics). If moving it to -internal serves another purpose and fixes other issues, then sounds good.

[geoand]

The internal module's purpose is to be used by the client that is created at deployment time, to deploy the application to k8s. It gets included in the public module which is used to provide the client used at runtime.

…

On Tue, Feb 7, 2023, 18:46 Marc Nuri ***@***.***> wrote: @manusa <https://github.com/manusa> can you remind me what the rationale was for putting QuarkusHttpClientFactory in quarkus-kubernetes-client instead of quarkus-kubernetes-client-internal? It seems to me like the later would make more sense as it would mean that it's always picked up. This was based on our private conversation, but there we didn't discuss about internal vs. non-internal. So probably I decided upon my understanding. I'm not sure about what the -internal module is used for (I don't recall seeing it in the guidelines). I guess my rationale is/was that users should be aware of the SPI-based HttpClient factory that Quarkus provides hence making it public (pure semantics). If moving it to -internal serves another purpose and fixes other issues, then sounds good. — Reply to this email directly, view it on GitHub <#30952 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBMDPYXJ3KBYOR7QIDTUI3WWJ347ANCNFSM6AAAAAAUT6Z334> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[Sgitario]

Now, it works perfectly, many thanks!

[geoand]

❤️