io.quarkus.kubernetes.deployment.OpenshiftDeployer throws java.io.IOException: Failed to resolve <host> but evidently did reach the host #31476
Labels
Milestone
Comments
|
@Sgitario could you have a look at this one when you have some time? It's blocking the deployment of our support apps to OpenShift and we would like to push as many apps with Quarkus 3 to gather feedback. Thanks! |
|
This is very related to #30951 which was meant to be fixed by #30952. I've been able to reproduce it on native as stated in the issue description, but also randomly on JVM. I think the problem is related to restoring the disable vertx DNS resolver system property right after creating the vert.x instance, so I'm changing a bit the workflow to do this after the build is finished (when the K8s resources will have been pushed to Kubernetes/OpenShift already). |
Sgitario
added a commit
to Sgitario/quarkus
that referenced
this issue
Mar 1, 2023
Sgitario
added a commit
to Sgitario/quarkus
that referenced
this issue
Mar 2, 2023
There were several places where a new KubernetesClient was being created: - Some places use `Clients.fromConfig`. - Other places use `KubernetesClientUtils.createConfig`. - And other places use `KubernetesClientBuildItem.getClient` And the problem is that every time we invoke any of these methods, Fabric8 KubernetesClient tries to locate one HttpClient.Factory and it seems that the logic to get one HttpClient.Factory sometimes gets the `VertxHttpClientFactory` implementation over the expected one `QuarkusHttpClientFactory` With this solution, it avoids to find a HttpClient.Factory using the ServiceLoader logic in Fabric8 Kubernetes Client, but it provides the expected `QuarkusHttpClientFactory` implementation always. Fix quarkusio#31476
Sgitario
added a commit
to Sgitario/quarkus
that referenced
this issue
Mar 2, 2023
There were several places where a new KubernetesClient was being created: - Some places use `Clients.fromConfig`. - Other places use `KubernetesClientUtils.createConfig`. - And other places use `KubernetesClientBuildItem.getClient` And the problem is that every time we invoke any of these methods, Fabric8 KubernetesClient tries to locate one HttpClient.Factory and it seems that the logic to get one HttpClient.Factory sometimes gets the `VertxHttpClientFactory` implementation over the expected one `QuarkusHttpClientFactory` With this solution, it avoids to find a HttpClient.Factory using the ServiceLoader logic in Fabric8 Kubernetes Client, but it provides the expected `QuarkusHttpClientFactory` implementation always. Fix quarkusio#31476
Sgitario
added a commit
to Sgitario/quarkus
that referenced
this issue
Mar 2, 2023
There were several places where a new KubernetesClient was being created: - Some places use `Clients.fromConfig`. - Other places use `KubernetesClientUtils.createConfig`. - And other places use `KubernetesClientBuildItem.getClient` And the problem is that every time we invoke any of these methods, Fabric8 KubernetesClient tries to locate one HttpClient.Factory and it seems that the logic to get one HttpClient.Factory sometimes gets the `VertxHttpClientFactory` implementation over the expected one `QuarkusHttpClientFactory` With this solution, it avoids to find a HttpClient.Factory using the ServiceLoader logic in Fabric8 Kubernetes Client, but it provides the expected `QuarkusHttpClientFactory` implementation always. Fix quarkusio#31476
Sgitario
added a commit
to Sgitario/quarkus
that referenced
this issue
Mar 2, 2023
There were several places where a new KubernetesClient was being created: - Some places use `Clients.fromConfig`. - Other places use `KubernetesClientUtils.createConfig`. - And other places use `KubernetesClientBuildItem.getClient` And the problem is that every time we invoke any of these methods, Fabric8 KubernetesClient tries to locate one HttpClient.Factory and it seems that the logic to get one HttpClient.Factory sometimes gets the `VertxHttpClientFactory` implementation over the expected one `QuarkusHttpClientFactory` With this solution, it avoids to find a HttpClient.Factory using the ServiceLoader logic in Fabric8 Kubernetes Client, but it provides the expected `QuarkusHttpClientFactory` implementation always. Fix quarkusio#31476
Sgitario
added a commit
to Sgitario/quarkus
that referenced
this issue
Mar 3, 2023
There were several places where a new KubernetesClient was being created: - Some places use `Clients.fromConfig`. - Other places use `KubernetesClientUtils.createConfig`. - And other places use `KubernetesClientBuildItem.getClient` And the problem is that every time we invoke any of these methods, Fabric8 KubernetesClient tries to locate one HttpClient.Factory and it seems that the logic to get one HttpClient.Factory sometimes gets the `VertxHttpClientFactory` implementation over the expected one `QuarkusHttpClientFactory` With this solution, it avoids to find a HttpClient.Factory using the ServiceLoader logic in Fabric8 Kubernetes Client, but it provides the expected `QuarkusHttpClientFactory` implementation always. Fix quarkusio#31476
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Since recently, with Quarkus 3.0.Alpha4, using
quarkus.kubernetes.deploy=trueleads to an error:See https://github.com/quarkusio/quarkus-github-lottery/actions/runs/4290767409/jobs/7479679333#step:6:30555
OpenShift seems to be reachable though, since I can see the deployment causes changes in OpenShift (a build is triggered and the pod restarts). It's stuck on an older version of my application, though.
It's probably a coincidence, but this failure started started to appear right after I upgraded to Maven Compiler Plugin 3.11.0: quarkusio/quarkus-github-lottery@2f75ba2
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
I don't have a reproducer but here is the project: https://github.com/quarkusio/quarkus-github-lottery/
Command:
See https://github.com/quarkusio/quarkus-github-lottery/blob/4a0f8d6655025fffa099396854de89d2fc3c1d73/.github/workflows/deploy.yml#L36-L43
Configuration:
See https://github.com/quarkusio/quarkus-github-lottery/blob/4a0f8d6655025fffa099396854de89d2fc3c1d73/src/main/resources/application.properties
Output of
uname -aorverNo response
Output of
java -versionNo response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.0.0.Alpha4
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: