Meta: Operator SDK's in other languages

[estroz]

There has been quite a bit of interest in writing an SDK for Java (#1568, #2728) and python (mentioned in slack and community meetings). In general the operator-framework community should support as many Operator SDK's, or one SDK that manages Operators in multiple languages, as possible since Operators are largely language independent. While this repo does not support scaffolding Operators in other languages aside from Go, Ansible, and Helm (yet), we welcome both documentation on how to build an SDK in any language or community projects that provide ergonomic abstractions over their language's k8s client library.

Some project that provide more abstract client libraries that we're aware of:

• Java:
  • https://github.com/fabric8io/kubernetes-client
• Python:
  • https://github.com/zalando-incubator/kopf

There is no official documentation discussing best practices for writing an SDK currently but there are plans to write one. In the mean time here are a few methodologies this SDK followed to become what it is today:

• Scaffold a basic project that can be built immediately and run with few changes
  • Project layout: Go, Ansible, Helm
  • Scaffolding code: Go, Ansible, Helm
  • Generators: controller-gen
• Leverage a runtime library that abstracts client-go into ergonomic, high-level APIs for managing Operator resources
  • controller-runtime
  • Runners that reconcile Ansible and Helm projects
• A binary with packaging and testing features
  • operator-sdk build
  • operator-sdk bundle
  • operator-sdk test

Feel free to comment in this meta-issue with links to other SDK-related projects, documentation suggestions, or questions about the above.

/kind documentation
/priority important-longterm

[brindasanth]

We shall use Kubernetes official java client project: https://github.com/kubernetes-client/java

[jkremser]

fyi https://github.com/jvm-operators/abstract-operator (I don't work for Red Hat anymore, though)

[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

[camilamacedo86]

/lifecycle frozen

[asmacdo]

This is valuable, but not actionable. IMO specific language RFEs should be filed if needed.