Chris Laprun

> @metacosm Thanks for your suggestions, I am trying to understand those > > don't you think it would be expensive to parse/evaluate with each call? What makes you think...

I guess this won't work with Quarkus 2.7…

How would you go about doing it, though? I don't have a lot of experience with shaded dependencies but have been bitten by them before so I would like to...

I've been thinking about trimming dependencies, yes. The initial idea was to have a "batteries-included, opinionated" extension but that might be causing more issues than really helping :) Do you...

I will remove it in the next major version of the extension.

I'm not sure what the proper solution is in this case but I'm definitely against crashing the operator because that would leave the door open for malicious actors to craft...

> > What do you mean by that? > > We can possibly emit an [event](https://banzaicloud.com/blog/k8s-cluster-logging/#access-event-logs), possibly on the user CR or, worst case, on the operator `Deployment` itself containing...

Why an informer, though? Couldn't we just deserialise the failed CR with `GenericKubernetesResource`?

How would a generic informer work, though? Would that mean having a constantly running informer watching all the resources?

> I think what @andreaTP means that, when an error occurs during de-serialization of a resource, we could try to de-serialize it to `GenericKubernetesResource`. And the error handler could work...