Meta: Operator SDK's in other languages #2745
Labels
kind/documentation
Categorizes issue or PR as related to documentation.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
needs discussion
priority/important-longterm
Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone
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:
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:
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
The text was updated successfully, but these errors were encountered: