Epic Goal

Assist pipelines building sqllite backed Catalogs to move over to building plain-text backed Catalogs
Ensure Catalog authors are aware of how to fully take advantage of the features that comes with plain-text backed Catalogs.
Standardize Catalog building/maintaining process through prototypes/example/best-practice recommendations

Why is this important?

So far, each Catalog building pipelines have spurred up their own way of building/maintain Catalogs. This has lead to unbounded feature requests from the olm team for bespoke tools to assist in maintaining each separate pipelines. That in turn has resulted in the need for an exponentially increasing amount of engineering cycles from the olm team to meet these feature requests/continue fixing bugs for these tools.
plain-text backed Catalogs are not yet being built in production. Assisting pipelines through dog food-ing plain-text backed Catalogs/demoing prototypes of the Catalog building process + receiving feedback and iterating for final touches will help Declarative Catalogs be ready for prime time action.

Some existing operator teams desire to continue using the current imperative workflow into 4.10+. How does this work?
Some existing operator teams will want to take advantage of FBC features beginning in 4.10, but must still publish bundles to 4.6-4.9 using the imperative workflow. How does this work?
Some new operator teams will want to publish only to 4.10+ using FBC. How does this work?
N pipelines (that do not share the same engineers) building Catalogs follow similar processes
Common feedback/Support request from pipelines are addresses by dev team through iterations

Where do operator teams store their FBC (veneer or otherwise)?
How does an operator team publish updates of their package's metadata to the destination catalog?
What policies should each step of the catalog building pipeline put in place to ensure only allowed updates are made and audited?
How does CVP need to change to adapt to the fact that bundles may be published without corresponding index updates?
How does CVP need to change to adapt to the fact that index updates may be published that do not change the set of bundles in a package (e.g. only package and channel-level metadata changes)?

Pipelines have a standard guideline for building and maintaining Catalogs via example Catalog/bundle repositories + documentation on those repositories/upstream doc site/downstream docs
Building and maintaining Catalogs takes significantly less amount of investment because plaintext backed Catalogs are both usable by dependency resolver while being user readable.
FAQs are documented with examples for common scenarios like building upgrade graphs for Operator packages, editing the upgrade graph for bundle channel promotion/adding new bundles in the graph etc.

CI - CI is running, tests are automated and merged.
DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
DOC - Downstream documentation merged: <link to meaningful PR>

Closed

Unassigned