Epic Goal

• SQlite catalog maintainers need a solution to facilitate veneer adoption.  The easiest capability to provide is migration to the basic veneer.  In addition, the mechanism needs to omit any properties from the original source which are no longer relevant in the new format.

Why is this important?

• Minimizing friction to veneer adoption is key to speeding the FBC transition

Scenarios

1. Maintainer wants to update legacy catalog to veneer
2. operator author wants to update their catalog contribution to veneer

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Documentation - MUST have supporting documentation easily available to catalog maintainers & operator authors
•  

Open questions::

1. for the migration path, is documentation of current solution (opm render +  yq/jq) sufficient or do we need to support in formal tooling (e.g. opm migrate + flag)?
2. are there any other obsolete properties we need to omit from rendered FBC?

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>