Epic Goal

SDK provides more reusable libraries to promote best practices when writing an Operator.

Why is this important?

This epic is important groundwork for enabling "Idiomatic way to write an Operator" by starting with SDK library provides small building blocks that could be composed into larger and larger patterns.

Red Hat Community of Practice (COP) group has created a utility library for writing an Operator and a lot of these have a higher abstraction of k8s, hence not directly tied to controller-runtimes, make these library features are perfect candidates be incorporated and added to operator-lib for SDK users (near-term) and ourselves as the building blocks for "Idiomatic Operator Pattern".

Acceptance Criteria

• Review Operator-utils functionality list from Red Hat COP group and identify the potential fits from the features of the utility libraries. Repos needs to be reviewed and considered:
  • https://github.com/redhat-cop/operator-utils
  • https://github.com/RHsyseng/operator-utils
  • https://github.com/halkyonio/operator-framework
  • https://github.com/darkowlzz/operator-toolkit - NEW

• Joe has completed the 1st pass of the review and triage (in OSDK-1239), need to sync up with Joe and see which buckets these utility libraries belong to:
  1. upstream to kubebuilder - scaffolding related improvements
  2. upstream to controller-runtime - controller helpers that are widely applicable to all Go operators
  3. upstream to operator-sdk - controller helpers that are applicable to the set of operators that are in-scope for operator-sdk, but not all Go operators
  4. add to new operator-framework repo - experimental, niche, or immature features, or anything that has some question about its longevity and maintainability
  5. add to new (or existing?) openshift repo - Openshift-specific features and helpers

• For examples, libraries that: 
  • allows easy to handle finalizers and deletion
  • reconciliation on a CR spec chases down to full resource hierarchy:
    • maps a CR spec to a list of child resources +
    • dynamically adds watches for those resources +
    • uses server-side apply to keep them up-to-date
  • supports CRD version migration
  • enables webhook based validation

• Integrate (if possible) or add the logic to SDK's operator-lib as the building blocks so SDK users can easily import and use them.

• Keep in mind how these utility libraries could be composed into larger and larger patterns

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>