Epic Goal

A novel implementation of the validator interface in the SDK and adding it to the set of external validators to be run for "bundle validate" command.

Why is this important?

Currently, the bundle validation rules are hosted in OperatorFramework's API with a version tag. Whenever the validation rules get updated, this requires the SDK project to release an updated SDK version with the binary baked in with the correct OF API's tag so that the SDK's "bundle validate" command can get the latest validation rules.

This creates several problems:

• SDK users (e.g. community pipelines, partner pipelines, or OCP downstream pipelines) need to wait until another SDK release in order to get the updated validation rules.
• No easy ways to host custom/vendor specific validation rules in the upstream Operator Framework API repo.
• No flexibility to include the validation rules from different sources (e.g. from a remote repo or from local disk).
• As OLM is looking to support deploying broader k8s object types in the Operator bundle in the future, it's important to provide a more scalable way to allow customizing the bundle validation rules.

We want to address all these problem at once with a novel architecture that includes a validator interface in the SDK project, a validator engine in the SDK, and it can drive a set of validators for "bundle validate" command.

Scenarios

1. Users want to edit/add/remove a set of validation rules for Operator bundle validation.
2. Users can host a set of validation rules either locally or in remote.
3. Users can define the target set of validation rules for SDK's bundle validation command (either from local or remote source).

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...
• Users can easily edit/add a set of validation rules for Operator bundle validation.
• Users can host a set of validation rules either locally or in remote.
• Users can define the target set of validation rules for SDK's bundle validation command (either from local or remote source).
• New upstream doc for introducing and guiding how to utilize this new feature in Operator projects.

Dependencies (internal and external)

1. ...

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>