microbean-kubernetes-controller
microbean-kubernetes-controller copied to clipboard
Track kubernetes-client issue 1099
I need to remove the reflection hacks to work around https://github.com/fabric8io/kubernetes-client/issues/1099 when that issue is finally fixed.
Looks like this is actually the case since releases past Aug. 28th. Do you have any plan to update the dependencies?
I've been holding off because judging by the various bug reports the 4.x line is more unstable than the 3.x line. If you want to try yourself, you can use <dependencyManagement>
stanzas in your pom.xml
appropriately.
Thanks that’s actually fine. I am content for the moment using the work around.
I've published a mostly untested SNAPSHOT
(0.2.3-SNAPSHOT
) to Sonatype snapshots that upgrades the Kubernetes client to 4.1.1. I'd be curious to see what you think.
Smashing 👍 i’ll definitely give it a shot soon. I’ll keep you posted.
So far all my unit and system tests are passing without issue. I'll move to actual applications over the week-end and let you know.
EDIT Does 4.1.1 solves the missing deserializer registration on your end? I am still getting the same error as with the older version:
java.lang.ClassCastException: io.fabric8.kubernetes.api.model.batch.Job cannot be cast to my.controller.crds.jobs.Job
at my.controller.crds.jobs.JobController.onAddition(JobController.java:357)
at my.controller.GenericEventQueueConsumer.accept(GenericEventQueueConsumer.java:28)
at org.microbean.kubernetes.controller.ResourceTrackingEventQueueConsumer.accept(ResourceTrackingEventQueueConsumer.java:254)
at org.microbean.kubernetes.controller.ResourceTrackingEventQueueConsumer.accept(ResourceTrackingEventQueueConsumer.java:48)
at org.microbean.kubernetes.controller.EventQueueCollection.lambda$createEventQueueConsumptionTask$1(EventQueueCollection.java:940)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
EDIT 2 Other instance of the same issue, without the name clashing:
2019-02-15 22:12:33 ERROR WatchHTTPManager:293 - Could not deserialize watch event: {"apiVersion":"v1","kind":"List", "items": [{"kind":"Export","apiVersion":"my.controller.com/v1alpha1","metadata":{"annotations":{"my.controller.com/applicationName":"apps.pubsub::Exporter","my.controller.com/applicationScope":"Default"},"labels":{"app":"myapp","job":"test"},"name":"test-0-2","namespace":"test","ownerReferences":[{"apiVersion":"my.controller.com/v1alpha1","kind":"Job","blockOwnerDeletion":true,"controller":true,"name":"test"}]},"spec":{"peId":0,"portId":2,"stream":{"properties":null,"exportOperName":"ExportOp2","name":"hcSectorBargains","allowFilter":true,"congestionPolicy":"WAIT"}}}], "metadata": {"resourceVersion":"v1alpha1"}}
com.fasterxml.jackson.databind.JsonMappingException: No resource type found for:my.controller.com/v1alpha1#Export
at [Source: N/A; line: -1, column: -1] (through reference chain: io.fabric8.kubernetes.api.model.KubernetesList["items"]->java.util.ArrayList[0])
at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:148)
at com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:867)
at io.fabric8.kubernetes.internal.KubernetesDeserializer.deserialize(KubernetesDeserializer.java:78)
at io.fabric8.kubernetes.internal.KubernetesDeserializer.deserialize(KubernetesDeserializer.java:32)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:217)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:25)
at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:520)
at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:95)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:258)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:125)
at com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:3708)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2005)
at com.fasterxml.jackson.databind.ObjectMapper.treeToValue(ObjectMapper.java:2476)
at io.fabric8.kubernetes.internal.KubernetesDeserializer.deserialize(KubernetesDeserializer.java:80)
at io.fabric8.kubernetes.internal.KubernetesDeserializer.deserialize(KubernetesDeserializer.java:32)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3736)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2726)
at io.fabric8.kubernetes.client.dsl.internal.WatchHTTPManager.readWatchEvent(WatchHTTPManager.java:312)
at io.fabric8.kubernetes.client.dsl.internal.WatchHTTPManager.onMessage(WatchHTTPManager.java:247)
at io.fabric8.kubernetes.client.dsl.internal.WatchHTTPManager$2.onResponse(WatchHTTPManager.java:176)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:206)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I seem to recall that it does not.
See the latest comment on OP, looks like your workaround is actually a required step :)
Interesting; particularly given that the class involved is from a package with internal
in the name.
OK, sounds like using this internal
class is considered not to be a hack (!). See https://github.com/fabric8io/kubernetes-client/issues/1285 as well.
Strictly speaking, the microbean-kubernetes-controller
library doesn't itself need to use this ~workaround~ sanctioned ~hack~ approach, so I will close this issue (unless you have something else to add here, @xguerin?) and consider releasing.
@ljnelson nope, I'am all good 👍