Graal Native Build missing ReflectionRegistrations in io.fabric8:kubernetes-model-core:5.12.3

[manuelwallrapp]

Describe the bug

Hi

The fix should be fast. I get following exception when running my native app do to missing ReflectionRegistrations:
Caused by: java.lang.NoSuchMethodException: io.fabric8.kubernetes.api.model.PersistentVolumeClaimBuilder.(io.fabric8.kubernetes.api.model.PersistentVolumeClaim)
at java.lang.Class.getConstructor0(DynamicHub.java:3585)
at java.lang.Class.getDeclaredConstructor(DynamicHub.java:2754)
at io.fabric8.kubernetes.client.ResourceHandlerImpl.edit(ResourceHandlerImpl.java:62)
... 38 more

I solved it by adding this class to my code:

import io.fabric8.kubernetes.api.model.ConfigMapBuilder;
import io.fabric8.kubernetes.api.model.PersistentVolumeClaimBuilder;
import io.quarkus.runtime.annotations.RegisterForReflection;

/**

• Temporary registration of external classes which should be fixed by the library in the future.
• This patch is neede for quarkus native build
• TODO remove as soon Openshif-Client library patched this bug
  */
  @RegisterForReflection(targets = {PersistentVolumeClaimBuilder.class, ConfigMapBuilder.class})
  public class RegisterReflections {

}

But it should be fixed in the library.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

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

No response

Additional information

No response

[quarkus-bot]

/cc @Sgitario, @geoand, @iocanel

[geoand]

Thanks for reporting!

Can you perhaps add the full stacktrace?

Furthermore, what does your code look like?

[manuelwallrapp]

I think the full Stacktrace is not even necessary, cause the fix is so easy as described above. The same behavior happened for io.fabric8.kubernetes.api.model.ConfigMapBuilder but here the full Stacktrace:

2022-08-23 16:35:26,321 ERROR [ch.sbb.est.tek.pip.ser.ope.OpenshiftTemplateService] (vert.x-eventloop-thread-4) Failed to modify and process template esta-tekton-pipeline-java-maven-build-run-template. Reason: An error has occurred.: io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
        at io.fabric8.kubernetes.client.ResourceHandlerImpl.edit(ResourceHandlerImpl.java:65)
        at io.fabric8.kubernetes.client.dsl.internal.NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl.acceptVisitors(NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl.java:245)
        at io.fabric8.kubernetes.client.dsl.internal.NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl.inNamespace(NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl.java:129)
        at io.fabric8.kubernetes.client.dsl.internal.NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl.inNamespace(NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl.java:63)
        at ch.sbb.esta.tekton.pipeline.service.openshift.OpenshiftTemplateService.lambda$processAndApplyTemplate$2(OpenshiftTemplateService.java:96)
        at java.util.ArrayList.forEach(ArrayList.java:1511)
        at ch.sbb.esta.tekton.pipeline.service.openshift.OpenshiftTemplateService.processAndApplyTemplate(OpenshiftTemplateService.java:92)
        at ch.sbb.esta.tekton.pipeline.service.openshift.OpenshiftTemplateService.processAndApplyWithTmpTemplate(OpenshiftTemplateService.java:73)
        at ch.sbb.esta.tekton.pipeline.service.openshift.OpenshiftTemplateService.modifyProcessAndApplyTemplate(OpenshiftTemplateService.java:65)
        at ch.sbb.esta.tekton.pipeline.service.openshift.OpenshiftTemplateService.modifyProcessAndApplyPipelineRunTemplate(OpenshiftTemplateService.java:50)
        at ch.sbb.esta.tekton.pipeline.service.openshift.OpenshiftTemplateService_ClientProxy.modifyProcessAndApplyPipelineRunTemplate(Unknown Source)
        at ch.sbb.esta.tekton.pipeline.service.pipelinestarter.PipelineExecutor.execPipelineRunFromTemplate(PipelineExecutor.java:68)
        at ch.sbb.esta.tekton.pipeline.service.pipelinestarter.PipelineExecutor.startPipeline(PipelineExecutor.java:52)
        at ch.sbb.esta.tekton.pipeline.service.pipelinestarter.PipelineExecutor_ClientProxy.startPipeline(Unknown Source)
        at ch.sbb.esta.tekton.pipeline.service.pipelinestarter.PipelineEventProcessor.startPipeline(PipelineEventProcessor.java:38)
        at ch.sbb.esta.tekton.pipeline.service.pipelinestarter.PipelineEventProcessor_ClientProxy.startPipeline(Unknown Source)
        at ch.sbb.esta.tekton.pipeline.service.pipelinestarter.PipelineEventProcessor_VertxInvoker_startPipeline_b2682422d03771df196866d5169809e873d6f3cf.invokeBean(Unknown Source)
        at io.quarkus.vertx.runtime.EventConsumerInvoker.invoke(EventConsumerInvoker.java:41)
        at io.quarkus.vertx.runtime.VertxRecorder$3$1.handle(VertxRecorder.java:130)
        at io.quarkus.vertx.runtime.VertxRecorder$3$1.handle(VertxRecorder.java:100)
        at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:264)
        at io.vertx.core.eventbus.impl.MessageConsumerImpl.dispatch(MessageConsumerImpl.java:177)
        at io.vertx.core.eventbus.impl.HandlerRegistration$InboundDeliveryContext.execute(HandlerRegistration.java:137)
        at io.vertx.core.eventbus.impl.DeliveryContextBase.next(DeliveryContextBase.java:72)
        at io.vertx.core.eventbus.impl.DeliveryContextBase.dispatch(DeliveryContextBase.java:43)
        at io.vertx.core.eventbus.impl.HandlerRegistration.dispatch(HandlerRegistration.java:98)
        at io.vertx.core.eventbus.impl.MessageConsumerImpl.deliver(MessageConsumerImpl.java:183)
        at io.vertx.core.eventbus.impl.MessageConsumerImpl.doReceive(MessageConsumerImpl.java:168)
        at io.vertx.core.eventbus.impl.HandlerRegistration.lambda$receive$0(HandlerRegistration.java:49)
        at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:833)
        at com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:705)
        at com.oracle.svm.core.posix.thread.PosixPlatformThreads.pthreadStartRoutine(PosixPlatformThreads.java:202)
Caused by: java.lang.NoSuchMethodException: io.fabric8.kubernetes.api.model.PersistentVolumeClaimBuilder.<init>(io.fabric8.kubernetes.api.model.PersistentVolumeClaim)
        at java.lang.Class.getConstructor0(DynamicHub.java:3585)
        at java.lang.Class.getDeclaredConstructor(DynamicHub.java:2754)
        at io.fabric8.kubernetes.client.ResourceHandlerImpl.edit(ResourceHandlerImpl.java:62)
        ... 38 more

[geoand]

I think the full Stacktrace is not even necessary, cause the fix is so easy as described above.

The fix may be easy, but I am interested in seeing what the root cause.

[geoand]

It seems from the stacktrace and looking at the code of ResourceHandlerImpl, that this same problem can occur for *BuilderClasses.

@iocanel @manusa which such classes other than PersistentVolumeClaimBuilder and ConfigMapBuilder can be part of that ResourceHandlerImpl flow?

[manuelwallrapp]

My code modifies a Tekton Pipeline Template, I hope that clarifies how we call it:

private HasMetadata createOrReplaceExHandled(HasMetadata templateItem) {
        try {
            return getOpenshiftClient().resource(templateItem).inNamespace(getNamespace()).createOrReplace();
        } catch (KubernetesClientException ex) {
            logCreateObjectException(templateItem, ex);
        }
        return null;
    }

[manusa]

@iocanel @manusa which such classes other than PersistentVolumeClaimBuilder and ConfigMapBuilder can be part of that ResourceHandlerImpl flow?

Any of the Kubernetes Model classes can be part of this flow. The class infers the Builder types by appending Builder to the model class name, and the List classes by appending List to the class name (e.g. Pod/PodBuilder/PodList).

I'm not sure how the current extension is registering the model classes now, but I think it would be safe to assume that if any model class is registered its complimentary Builder and List classes should be registered too.

[geoand]

Makes sense, thanks

[geoand]

It seems like we currently register all implementations of io.fabric8.kubernetes.api.model.KubernetesResource.
So are you proposing we extend that to those classes plus their List and Builder suffixes?

[manusa]

So are you proposing we extend that to those classes plus their List and Builder suffixes?

All XXXList classes should already implement the KubernetesResource interface, so those might be covered depending on how classes are discovered or filtered. AFAIR not all KubernetesResources are registered, but only those that are in use.

So yes, for any implementation of KubernetesResource that is discovered and that is not a KubernetesResourceList, we should make sure that the accompanying List and Builder classes are registered too just in case (not sure about the XXXFluentImpl, or any implementation of the XXXFluent interface).

So (maybe I'm missing some class) for a resource Pod, we might end up using:

• PodList
• PodBuilder
• PodFluentImpl (PodFluent interface implementation)

For Generic resources (I'm not sure if this was covered) that are used as fallback for unknown types, we should always include:

• GenericKubernetesResource
• GenericKubernetesResourceList
• GenericKubernetesResourceBuilder
• GenericKubernetesResourceFluentImpl (GenericKubernetesResourceFluent)