Chris Laprun

Hi, @wtrocki Could you elaborate on the use case you have in mind? How would things work for you, ideally?

Do you have the same issue running in JVM mode?

I'd argue that the samples should maybe be in a different repository. A generator to generate a skeleton operator would also help.

@charlottemach you mentioned you were interested in taking this on during the last weekly call, is it still the case?

Maybe the strategy should be configurable i.e. the framework would support event replication but let users activate or deactivate it depending on their needs?

Can you detail under which circumstances, there would be such a high load that the SDK wouldn't process the primary soon enough? Slow dependent reconciliation? Load on the operator process...

Maybe we could add contention detection on the executor and issue a warning if processing takes longer than a given amount of time to let users know they might need...

Yes, was thinking about using metrics for that in a first step, indeed. Coupled with alerting (for people who are interested in such signal) would work nicely enough, imo.

> Didn't follow the comment on what version of operator sdk is used with what quarkus? What is that referring to? How would that change ? Users have historically been...

This is indeed something we need to take into account, and while we could release new versions of JOSDK to deal with this, it definitely wouldn't be very elegant.