Goal

SDK works with OLM to create a showcase Operator that implements all our design guidance and best practices and we (as the "Operator Framework" team) need to be its packaging and release maintainers.

Why is this important?

SDK and OLM need to provide clear guidance and toolings to upstream and downstream users (Operator projects users, ISVs, and/or Red Hat layered product teams) to be effective for Day 2 use cases, e.g. tests, releases, and migrations of their Operator and/or Operands, etc.

In order to always keep these concerns in our minds and put ourselves in the position of an Operator author, we (SDK and OLM team) should own and maintain a showcase Operator.

The showcase Operator will be a live example of how we think an Operator should be designed, released, and tested with the SDK and being managed by OLM to provide a great user experience in production and across updates.

Scenarios

1. Where are examples for CI flows for a non-Red Hat person to continuously build and test bundles?
2. Where are examples CD flows today for a non-Red Hat person to continuously release Operators into a catalog?
3. What are established strategies around updating Operator metadata only without releasing a new version?
4. What is the lifecycle of an Operator across channels?
5. Are there examples for Operators migrating CRDs and/or Operands across major versions?
6. How do I use Operators with my apps consuming their services?
7. Are there examples for Operators using Operand metrics and logs to make lifecycle decisions?
8. How do I communicate and guide cluster-admin during OCP upgrades?
9. How do I lower the blast radius of an Operator update gone bad?

Acceptance Criteria

• OF has ready-to-use release tooling and pipelines (preferably a mainstream one e.g. Tekton) to continuously ship an Operator, e.g. using GitHub actions
• A showcase Operator that uses the SDK and the above upstream release tooling to publish bundles and catalogs
• The showcase Operator can continuously migrate Operand versions and its APIs
• The showcase Operator’s release model only brings a subset of the version history to every supported k8s release
• The showcase Operator implements proper resource clean up and validation
• The showcase Operator is compatible with Service Binding
• The showcase Operator has comprehensive test coverage including kuttl/scorecard
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. (internal) Work with OLM and Portfolio Enablement team (Jeff's team) to develop and maintain the needed toolings and the showcase Operator.

Previous Work (Optional):

1. …

Open questions::

1. …

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>