Open rsvoboda opened 1 month ago
CC @gsmet @aureamunoz Also @metacosm as you discussed fabric8 during Tuesday call
So it's because of kubernetes-client bump in https://github.com/quarkusio/quarkus/pull/42450
Downgrading kubernetes-client from 6.13.3 back to 6.13.1 makes Stork work again. CC @manusa
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.
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… 🤔
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.
The issue we're seeing happens in JVM mode. Nothing to do with native.
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?
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).
Stork does not do anything at build time, this is pure runtime.
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.
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.
We released a Stork 2.6.1 to workaround the issue.
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: