Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stork-kubernetes-quickstart is failing with the latest Quarkus main #1442

Open
rsvoboda opened this issue Aug 15, 2024 · 12 comments
Open

stork-kubernetes-quickstart is failing with the latest Quarkus main #1442

rsvoboda opened this issue Aug 15, 2024 · 12 comments

Comments

@rsvoboda
Copy link
Member

stork-kubernetes-quickstart is failing with the latest Quarkus main

https://github.com/quarkusio/quarkus-quickstarts/actions/runs/10397663385/job/28793729373

Caused by: java.lang.NoSuchMethodError: 'io.fabric8.kubernetes.client.ConfigFluent io.fabric8.kubernetes.client.ConfigBuilder.withMasterUrl(java.lang.String)'

Details:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.FrontendApiResourceTest
2024-08-15 03:14:40,993 INFO  [okh.moc.MockWebServer] (MockWebServer 60193) MockWebServer[60193] starting to accept connections
2024-08-15 03:14:41,617 INFO  [okh.moc.MockWebServer] (MockWebServer 60193) MockWebServer[60193] done accepting connections: Socket closed
Error:  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.601 s <<< FAILURE! -- in org.acme.FrontendApiResourceTest
Error:  org.acme.FrontendApiResourceTest.testApiEndpoint -- Time elapsed: 0.011 s <<< ERROR!
java.lang.RuntimeException: java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:643)
	at io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:727)
	at java.base/java.util.Optional.orElseGet(Optional.java:364)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
Caused by: java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at io.quarkus.runner.bootstrap.StartupActionImpl.run(StartupActionImpl.java:305)
	at io.quarkus.test.junit.QuarkusTestExtension.doJavaStart(QuarkusTestExtension.java:248)
	at io.quarkus.test.junit.QuarkusTestExtension.ensureStarted(QuarkusTestExtension.java:610)
	at io.quarkus.test.junit.QuarkusTestExtension.beforeAll(QuarkusTestExtension.java:660)
	... 1 more
Caused by: java.lang.NoSuchMethodError: 'io.fabric8.kubernetes.client.ConfigFluent io.fabric8.kubernetes.client.ConfigBuilder.withMasterUrl(java.lang.String)'
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscovery.<init>(KubernetesServiceDiscovery.java:85)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProvider.createServiceDiscovery(KubernetesServiceDiscoveryProvider.java:31)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProvider_ClientProxy.createServiceDiscovery(Unknown Source)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProviderLoader.createServiceDiscovery(KubernetesServiceDiscoveryProviderLoader.java:33)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProviderLoader_ClientProxy.createServiceDiscovery(Unknown Source)
	at io.smallrye.stork.Stork.createService(Stork.java:205)
	at io.smallrye.stork.Stork.<init>(Stork.java:127)
	at io.smallrye.stork.Stork.initialize(Stork.java:276)
	at io.quarkus.stork.SmallRyeStorkRecorder.initialize(SmallRyeStorkRecorder.java:27)
	at io.quarkus.deployment.steps.SmallRyeStorkProcessor$initializeStork1271227497.deploy_0(Unknown Source)
	at io.quarkus.deployment.steps.SmallRyeStorkProcessor$initializeStork1271227497.deploy(Unknown Source)
	... 8 more
@rsvoboda
Copy link
Member Author

CC @gsmet @aureamunoz Also @metacosm as you discussed fabric8 during Tuesday call

@rsvoboda
Copy link
Member Author

So it's because of kubernetes-client bump in quarkusio/quarkus#42450

Downgrading kubernetes-client from 6.13.3 back to 6.13.1 makes Stork work again. CC @manusa

@manusa
Copy link

manusa commented Aug 15, 2024

This is extremely weird.
I'm off until the 26th, I'll reach out to @metacosm when I'm back to see what he found out.

@metacosm
Copy link

metacosm commented Aug 15, 2024

CC @gsmet @aureamunoz Also @metacosm as you discussed fabric8 during Tuesday call

Yeah, that's a manifestation of the issue I was discussing on the call except somewhat weirder because this isn't dealing with boxed vs unboxed types… 🤔

@gsmet
Copy link
Member

gsmet commented Aug 17, 2024

Are you sure it's not a problem with the builder being generated in the Kubernetes Client?

Because it's not even native failing and it looks like the method is simply not around.

@metacosm
Copy link

The issue we're seeing happens in JVM mode. Nothing to do with native.

@gsmet
Copy link
Member

gsmet commented Aug 17, 2024

That's what I wrote :).

My guess is that the new client is just binary incompatible. Maybe the return type has changed slightly (in the binary, the return type is also part of the signature).

My guess is that we just need a new Stork version compiled with 6.13.3.

@aureamunoz you around to do that?

@manusa
Copy link

manusa commented Aug 19, 2024

That's the thing, it should be binary compatible from the child class ConfigBuilder.
The problem seems to be that references are kept to the internal parent classes (that no longer exist or contain such methods) to reach their builder methods. But AFAIU this shouldn't be a problem for a regular Java execution. It might be related to the fact that Quarkus moves the processing to build time (but this is a wild guess).

@cescoffier
Copy link
Member

Stork does not do anything at build time, this is pure runtime.

@gsmet
Copy link
Member

gsmet commented Aug 19, 2024

I don't think so. My guess is that it's a pure Java issue and it's really as simple as the signature has changed (for whatever reason).
Binary compatibility can be tricky.

@manusa
Copy link

manusa commented Aug 19, 2024

I guess the problem is that 6.13.3 is source compatible but not binary compatible with 6.13.1.
Stork's bytecode might be holding a reference to ConfigFluent and the internal methods there instead of referencing ConfigBuilder itself (this can probably be checked by inspecting the produced byt code of the class that caused the NPE.
Sadly, this means that both dependencies need to be bumped simultaneously.

@cescoffier
Copy link
Member

We released a Stork 2.6.1 to workaround the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants