Feature Overview

Enable Java users to leverage existing Operator SDK UX and cloud-native tooling (Quarkus) to write Operators and being managed by OLM.

Goals

Bring Java talents to:

• manage distributed Java apps in the same language + existing libraries w/o steep learning curve
• write Java apps leveraging Quarkus for fast startup time and lower memory footprint
• easily integrate with OLM to enable more upstream communities/partners into our Operator Framework ecosystem

Requirements

• Operator project scaffolded in Java using Kubebuilder plugins
• Java libraries that provide:
  • scaffolding the reconciliation
    • an abstraction to Operator reconciliation loops

• • exposing metrics
    • Operator default metrics
    • Operator/Operands’ custom metrics

• • abstraction writing Webhooks
    • validating/mutating admission webhook
    • conversion webhook

• • Common abstractions around the lifecycle of a managed app
    • Operator version updates / migration
    • Operand version updates / migration

• Integration with OLM
  • generate bundle / bundle validate
  • run bundle / run bundle-upgrade

• Integration with scorecard
• Tooling to build Java Operator binaries
  • Java Operator SDK has its release cadence and is not tied to Operator SDK

Why is this important

Feedback from various partners and customers has been that Java remains a dominant programming language skill in corporate environments. There is much more market penetration for Java developers in the market than for Golang developers. Since the SDK should drive ISVs, partners and customers to bring their workloads to OpenShift using Operators, it is important we meet these people where they are with their skills. Removing the language skill barriers brings us closer to this goal.

Background

Java has a strong foothold in the commercial / enterprise software space. It is usually much easier for Enterprises to find developers with Java skills than, e.g. Golang skills in the market. On top of that there is a lot of tooling around Java to ensure compliance and security when delivering software to highly regulated industries, e.g. financial services. In these verticals companies writing Operators to provide managed Java-based workload are often meeting prohibitive barriers when trying to ship Golang-based projects since the existing compliance tooling is not compatible and may not even exist for Golang.

Documentation Considerations

• Does this feature have doc impact?
  • New content. Support for a new supported language will be added to the Operator SDK.

• What concepts do customers need to understand to be successful in [action]?
  • Following the documented minimum requirements and installation procedure.

• How do we expect customers will use the feature? For what purpose(s)?
  • Develop Operator in Java to manage their app/services in Java as well to leverage existing tooling and libraries.

• What reference material might a customer want/need to complete [action]?
  • Install Operator SDK and Java tooling as prerequisites.
  • Initiate an Operator project using Java/Quarkus plugin
  • Create APIs/controllers using Java/Quarkus plugin
  • Implement the controllers
  • Build and run the Operator
  • OLM integration

• Is there source material that can be used as reference for the Technical Writer in writing the content?
  • Upstream docs from the engineering team