Using the Quarkus extension of Java Operator SDK

[mabulgu]

I am playing with the Quarkus extension of the Java Operator SDK recently, for a talk I am preparing for and found it very promising in terms of development ease and small features they have + having the chance to run the operator natively.

https://github.com/quarkiverse/quarkus-operator-sdk

WDYT?

I guess our access operator is not that big and it would not be a huge deal to do the shift (needs some effort for sure).

Here is a good article series for the Quarkus extension: https://developers.redhat.com/articles/2022/02/15/write-kubernetes-java-java-operator-sdk

(and yes I am looking at these kinda stuff during my paternity leave🤦)

[scholzj]

I think @katheris Intentionally wanted to avoid using the Quarkus extension for the time being.

[mabulgu]

I think @katheris Intentionally wanted to avoid using the Quarkus extension for the time being.

Oh, I see. Then let's wait for her to hear what she thought because I did not see any major problem with the extension except for using yet another library (or putting another layer between).

I especially liked the idea of being able to use the operator-sdk cli with it and having the benefits of using Quarkus, like native build.

I am pretty new in the java operators field so let's see what she says as she is more experienced with these. Thanks!

[scholzj]

I especially liked the idea of being able to use the operator-sdk cli with it and having the benefits of using Quarkus, like native build.

FYI: The native build does not really work for us as it cannot do cross-platform compilation for the other platforms we support. So we had to abandon it for the projects using Quarkus such as Drain Cleaner.

[mabulgu]

@katheris any comments on this one? Why did we avoid using the one with Quarkus extension? To me it seems promising but I wonder what your concerns were.

[katheris]

Hey @mabulgu, there were a few reasons. Firstly, I am not very familiar with Quarkus, so it seemed sensible to only learn one new framework (i.e. Java Operator SDK), rather than needing to be familiar with two. Secondly it adds another set of dependencies that we rely on. So for example if a new version of JOSDK comes out we need to wait for the Quarkus plugin to also be updated before we can use it. Plus it adds another barrier to other Strimzi contributors to contribute to this component. Finally, when I reviewed the benefits of using Quarkus I wasn't convinced that they outweighed the other drawbacks I already listed. If you think that the benefits are worth it then I'm open to being convinced otherwise.

[mabulgu]

Hi @katheris. Some of the reasons that I think the Quarkus Operator SDK can be advantageous:

1- Being able to do DI 2- Native build possibilities (but AFAIU this is not an option, well at least for now) 3- Testing: The dev services makes it very easy to leverage testcontainers. For example: https://github.com/SystemCraftsman/java-operator-sdk-demo-javaday-ist-2023/blob/main/src/test/java/com/systemcraftsman/kubegame/test/OperatorFunctionalTest.java Thinking the Acecss operator needs some integration tests to be implemented, using Quarkus would make it too easy TBH. Testcontainers can be leveraged without Quarkus of course, but this is a matter of making things "easy". 4- Easy integration with the supported libs/tools which is a quite good advantage for an operator. 5- Because of 1..4 ease of development experience 6- Quarkus is "kubernetes-native" already so why not:)) (j/k)

I hear you and get your point about keeping it more minimalistic and I agree that JOSDK is quite new already which both effects the learning curve and maintenance.

I just loved how those folks wrapped JOSDK and used it which is one of the reasons I thought it would not put much further risk, as the implementation is not that complex. But yeah things happen. So in the end this becomes yet another arch tradeoff:)

Closing this issue as I wanted to understand your thoughts on this.