Goal:
Provide an abstraction for writing Operators to increase productivity/quality by defaulting to the best practices (with easy opt-in/out).

Benefits:

• Increase developer productivity and average Operator quality. Make tapping into best practices a default.
• “Less focus on code scaffolding, more focus on app lifecycle model”
• Users only need to define mapping functions and the library handles the rest.
  • no direct interaction and understand of lower-level libraries (e.g. c-r)
  • similar to helm-operator pattern (and/or “kustomize-based” controller)
• Open the door for more programming language support by SDK: e.g. Java, Python, etc

Why is this important:

• Despite the SDKs scaffolding features, there are still repetitive patterns and code that emerge when writing an Operator.
• Certain best practices are requiring awareness on the Operator author-side which is not necessarily widespread.

This feature will help Operator authors break free from writing most of the logic figuring out which version of the app to deploy, whether it should enable certain flags for the app deployment, and whether it's going to deploy on OpenShift or not, by providing easy mapping/opt-in or opt-out configurations and/or best practices. Hence, the Operator can less focus on code scaffolding, but more on the app lifecycle model and/or the business logic of the workload and truly deliver a mature Operator that is closer to the high-end of the capability level.

Acceptance criteria:

• a standard model for reconciliation is developed
• reconciliation logic is no longer written directly in a loop but constructed from code logic that is associated with events
• direction interaction / understanding of controller-runtime is no longer required
• Operator authors could easily adopt the best practices in developing the Operator but with an option to opt-out of them if they prefer.