Epic Goal

Operator authors/pipelines can run validation checks to ensure OLM can successfully install the Operator without hitting two known failed cases.

Why is this important?

Currently, two known cases will lead to OLM failing to install the Operator bundle:

1. an empty CRD description (see: owned/ required CRD) in the included CSV YAML/manifest
2. an OLM unsupported k8s resource YAML/manifest(s) is included (see: supported resources)

Operator Framework project should provide bundle validation checks for these two known failed cases so the error should be identified early by the Operator authors or in the pipelines rather than failing the installation in a live/production/managed service cluster.

Scenarios

1. Operator authors/pipelines can use Operator SDK to validate the Operator bundle(s) to ensure the Operator bundle can be successfully installed by the OLM.

Acceptance Criteria

• Establish a set of checks as a validator so Operator authors/teams/pipelines can valid the Operator bundle to ensure OLM can successfully install the Operator.

• Red Hat pipeline teams to enable this validating checks for bundles.
•  
•  
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Related Info:

1. OLM supported resources
2. Two static validations: requested from the Service Delivery

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>