Operator-sdk: Java operator sdk

[magick93]

Feature Request

As you are probably aware Java is one of the more popular languages. Supporting Java in the Operator-sdk would significantly increase its audience. I certainly would be more interested in using this project as I wouldnt have to learn go.

I'm sure many others would also take warmly to a java option.

[spanichella]

I agree on this, supporting Java in the Operator-sdk would significantly increase its audience.

[jbrisbin]

At Instana we created an Operator for our agent based on Quarkus [1] that we intend to refactor into a reusable library after we've productionized the alpha. It includes leveraging CDI injection for getting access to services that Operators need and emits CDI events on important lifecycle events, among other things. I hope this effort would work with the Quarkus dev community to leverage their support for this as it usually makes more sense in the Java world to leverage a library than to do code generation like is done in the golang SDK.

I would really like to be involved in discussions around what the Java SDK actually is as well, as some see the Go SDK CLI being leveraged to create artifacts in Java while others see pure Maven/Gradle support and libraries as the way to go (no pun intended). It's worth some discussion IMO.

[1] - https://github.com/instana/instana-agent-operator

[lilic]

Thanks for the feature request. If there is any specific things you would like to see being used, best practices etc, in the java operator type please list below. Similar as to how @jbrisbin did it, always good to get information ahead of time!

[shawn-hurley]

Hello All,

I think that the features that I think a bare minimum operator framework
needs are:

1. Informers - A watch mechanism that handles the watching of events and
   then publishes them onto a queue for the controller's worker/reconciler to
   handle. I think that for some programming languages this is easier than
   others, but I think the pattern should probably be used in most cases. This
   informer also has to keep a in memory cache of all the resources that it is
   watching.
2. The ability for the client of the controller/operator/reconciler to
   query that cache to reduce load on the api-server.

What do people think of these? Are there more that anyone sees?

Thanks,

Shawn Hurley

On Fri, Jun 21, 2019 at 5:09 AM Lili Cosic [e-mail] wrote:

Thanks for the feature request. If there is any specific things you would
like to see being used, best practices etc, in the java operator type
please list below. Similar as to how @jbrisbin
https://github.com/jbrisbin did it, always good to get information
ahead of time!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/operator-framework/operator-sdk/issues/1568?email_source=notifications&email_token=AAONV52J3JIOXXTRHNHPJFLP3SLD5A5CNFSM4HY4CTB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYH5F3A#issuecomment-504353516,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAONV574CRVJ67NV73AQQFLP3SLD5ANCNFSM4HY4CTBQ
.

[lilic]

cc @cmoulliard I believe you had an interest in java type operators as well. ^

[cmoulliard]

Yep like also @rhuss @jkremser

[cmoulliard]

Are there more that anyone sees?

Definitively. My list included also the following features

• Registration of the CRDs resources to be watched: primary and secondary
• Notification when a K8s resource has been created, updated or deleted (=> informer ?)
• Cache managing the k8s watched resources (to avoid to query time the k8s every time)
• Status management (= aggregate status of 2nd resources, ...)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[rhuss]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[rhuss]

/lifecycle frozen

[techthumb]

https://github.com/ContainerSolutions/java-operator-sdk looks to build this feature set

[estroz]

Meta-issue for non-Go Operator SDK's: #2745.