Goal: Allow developers to incrementally mature their Operator by allowing to mix and match helm-, ansible- and golang based logic.

Benefits hypothesis: Geting more people started in writing Operators with a low entrance barrier like helm and a roadmap to move further to the right on the capability model.

Why is this important: Many Operators today are rather simplistic, often not going beyond simple deployment of standard Kubernetes resources. Though this constitutes an Operator, it does not live up to the promise of Operator capabilities to offer application-specific lifecycle logic beyond what Kubernetes built-in controller can achieve. Giving developers a roadmap on how to add custom logic to their Operator without starting a completely new project is important to the overall maturity of Operators.

Acceptance criteria:

• SDK project is not tied anymore to a single implementation type (Helm, Ansible, Golang)
• developers can use different programming models per CRD type or even with further granularity
• developers can start with a helm-based or kustomize-based Operator, continue to add ansible playbook logic and eventually add gocode and keep maintaining these part independently

Engineering Notes

Currently, there is an implementation of hybrid operator project here. 

Start by creating a sample hybrid operator project from scratch, weigh the pros/cons of current implementation, and start discussion on next steps. Create an EP outlining the important aspects of the project for moving forward.

• Related resources: https://docs.google.com/document/d/1WGIPomclwUZsTe3_ubLbfafmjlJXxMDe31WuXdPm-W8/edit
• Sample project: https://github.com/anmol372/hybrid-matrix-operator