Issue with the loading of resources using the Kubernetes client in Quarkus 2.14.x in native mode

[PierreBtz]

Describe the bug

See https://github.com/PierreBtz/quarkus-kubernetes-client-bug for a reproducer.

Loading resources with a call like kubernetesClient.load(anInputStream).get() ends up with the following error in native mode:

io.fabric8.kubernetes.client.KubernetesClientException: Cannot edit io.fabric8.kubernetes.api.model.apps.Deployment with visitors, no builder was found
	at io.fabric8.kubernetes.client.impl.ResourceHandlerImpl.edit(ResourceHandlerImpl.java:61)
	at io.fabric8.kubernetes.client.dsl.internal.NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableListImpl.acceptVisitors(NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableListImpl.java:292)
// ommited for brievity, see the full stack in the README of the reproducer https://github.com/PierreBtz/quarkus-kubernetes-client-bug. 

Expected behavior

Resource is properly loaded, like in non native mode and in Quarkus 2.13.x.

Actual behavior

The resource is not loaded, it seems like a (multiple?) class is missing:

io.fabric8.kubernetes.client.KubernetesClientException: Cannot edit io.fabric8.kubernetes.api.model.apps.Deployment with visitors, no builder was found

How to Reproduce?

See attached repository: https://github.com/PierreBtz/quarkus-kubernetes-client-bug

Output of uname -a or ver

Darwin MAC-pbeitz.local 21.6.0 Darwin Kernel Version 21.6.0: Thu Sep 29 20:13:56 PDT 2022; root:xnu-8020.240.7~1/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk version "17.0.5" 2022-10-18 (same with openjdk version "11.0.13" 2021-10-19 LTS)

GraalVM version (if different from Java)

22.3.0

Quarkus version or git rev

2.14.2 or 2.14.1

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.1

Additional information

After quickly looking in the history of the project, I suspect that the bump of the fabric8 client from 5.x to 6.x is the cause of the issue but I didn't debug further.

[quarkus-bot]

/cc @Sgitario, @geoand, @iocanel

[geoand]

cc @manusa

Seems like there are some classes we should be registering for reflection

[manusa]

This class should be definitely registered for reflection and AFAIR is thoroughly tested.

I'm understanding right that this is actually happening in 2.14, but wasn't before?

Are you using the explicit type elsewhere in your project?

Might be related to or same as fabric8io/kubernetes-client#4593 (looks suspiciously alike)

[PierreBtz]

I'm understanding right that this is actually happening in 2.14, but wasn't before?

Correct I had this code running correctly in 2.13.x.

Are you using the explicit type elsewhere in your project?

No.

Might be related to or same as fabric8io/kubernetes-client#4593 (looks suspiciously alike)

Indeed this looks close and it's possible this fix would also fix this issue, however I had a look in "jvm mode" and there is a builder available so I suppose it's not properly registered for reflection (anymore?). This is surprising since the builder class name didn't change (package included) between the two versions.

[manusa]

It's likely that if you use the type explicitly in your code, then the native problem will be fixed (just create a dummy method that returns a Deployment).

[PierreBtz]

Registering for reflection works, but then I end up with an issue with the next builder (DeploymentBuilder), then the next, again and again for each Kubernetes object kinds. So I confirm that this is a potential workaround but not ideal :)

[manusa]

I didn't say to register for reflection, I suggested to use the type explicitly in your code (Quarkus should detect it and register the type, its builder, and List for you) to see if the problem goes away.

To check if this specific problem is related to the issue I linked you could try to register for reflection the DeploymentBuilder class (only). Internally we were using this to change the namespace at runtime. With the fix this is no longer done and shouldn't cause further trouble with Quarkus native.

[PierreBtz]

To check if this specific problem is related to the issue I linked you could try to register for reflection the DeploymentBuilder class (only).

Indeed, this way it fixes the issue with the namespacebuilder but I then also need to register JobBuilder.

I suspect I would have to register more to load other resources with more Kubernetes objects.

I didn't say to register for reflection, I suggested to use the type explicitly in your code (Quarkus should detect it and register the type, its builder, and List for you) to see if the problem goes away.

Indeed I confirm (but since there is absolutely no reason for me to directly call the builders, I find it cleaner to register for reflection the two needed builders).

Might be related to or same as fabric8io/kubernetes-client#4593 (looks suspiciously alike)

I tested my reproduction case against the head of the kubernetes-client and I confirm the issue is no longer present, so chances this commit is fixing the issue are quite highs :)

[manusa]

Sorry, maybe I was misleading. I'm only asking about using the explicit type or registering the builder to rule out if the issue is related. This shouldn't be used as a workaround, especially if you don't know the nature of the resources you might be loading.

We should cut a 6.3 release this week, and bump the quarks dependency as soon as it's out.

[PierreBtz]

My bad I misunderstood the intent :)

So I confirm simply importing the DeploymentBuilder and JobBuilder classes are enough in my case. Version 6.3, when it's out will also fix the issue, so the PR bumping to 6.3 in Quarkus will solve this issue :)

Thanks for your help.

[manusa]

Nice, thx for confirming 👍

[PierreBtz]

Confirming that the bug is fixed with Quarkus 2.16.0.RC1, closing now.