OCP/Telco Definition of Done
Epic Template descriptions and documentation.

Epic Goal

• As someone installing a new OCP cluster, I want the OLM v1 components automatically deployed as part of the cluster installation process managed by the CVO.

Why is this important?

• So users can try to use OLM v1

Scenarios

1. OLM v1 operator is installed by the CVO
2. OLM v1 operator reports the appropriate statuses on its ClusterOperator resource to allow the CVO to proceed to other second level operators
   1. This just needs to be the bare minimum to report the status as Available, not Degraded, etc.
   2. Future epics will expand the implementation to be more of a proper, full-featured second level operator
   3. This is ok at this time because this is TechPreviewNoUpgrade

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• When an OCP cluster is created with TechPreviewNoUpgrade:
  • The OLM v1 second level operator is running
  • The OLM v1 components (catalogd, rukpak, operator-controller) are running
  • The OLM v1 second level operator's ClusterOperator status reports that it is available/healthy/etc.

Dependencies (internal and external)

1. Standard CVO functionality

Previous Work (Optional):

1. N/A

Open questions::

1. N/A

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>