Epic Goal

• Allow Operator Authors to easily change the layout of the update graph in a single location so they can version/maintain/release it via git and have more approachable controls about graph vertices than today's replaces, skips and/or skipRange taxonomy
• Allow Operators authors to have control over channel and bundle channel membership

Why is this important?

• The imperative catalog maintenance approach so far with opm is being moved to a declarative format (OLM-2127 and OLM-1780) moving away from bundle-level controls but the update graph properties are still attached to a bundle
• We've received feedback from the RHT internal developer community that maintaining and reasoning about the graph in the context of a single channel is still too hard, even with visualization tools
• making the update graph easily changeable is important to deliver on some of the promises of declarative index configuration
• The current interface for declarative index configuration still relies on skips, skipRange and replaces to shape the graph on a per-bundle level - this is too complex at a certain point with a lot of bundles in channels, we need to something at the package level

Scenarios

1. An Operator author wants to release a new version replacing the latest version published previously
2. After additional post-GA testing an Operator author wants to establish a new update path to an existing released version from an older, released version
3. After finding a bug post-GA an Operator author wants to temporarily remove a known to be problematic update path
4. An automated system wants to push a bundle inbetween an existing update path as a result of an Operator (base) image rebuild (Freshmaker use case)
5. A user wants to take a declarative graph definition and turn it into a graphical image for visually ensuring the graph looks like they want
6. An Operator author wants to promote a certain bundle to an additional / different channel to indicate progress in maturity of the operator.

Acceptance Criteria

• The declarative format has to be user readable and terse enough to make quick modifications
• The declarative format should be machine writeable (Freshmaker)
• The update graph is declared and modified in a text based format aligned with the declarative config
• it has to be possible to add / removes edges at the leave of the graph (releasing/unpublishing a new version)
• it has to be possible to add/remove new vertices between existing edges (releasing/retracting a new update path)
• it has to be possible to add/remove new edges in between existing vertices (releasing/unpublishing a version inbetween, freshmaker user case)
• it has to be possible to change the channel member ship of a bundle after it's published (channel promotion)
• CI - MUST be running successfully with tests automated
• it has to be possible to add additional metadata later to implement OLM-2087 and OLM-259 if required

Dependencies (internal and external)

1. Declarative Index Config (OLM-2127)

Previous Work:

1. Declarative Index Config (OLM-1780)

Related work

• https://docs.google.com/document/d/1RR8EQ-7VEi0ItlnKsbHBlnSP8M1MaI0J5gSbqc9JM2w/edit#heading=h.gscpgotgkcn3\
• OLM-2087

Open questions:

1. What other manipulation scenarios are required?
   1. Answer: deprecation of content in the spirit of OLM-2087
   2. Answer: cross-channel update hints as described in OLM-2059 if that implementation requires it

When working on this Epic, it's important to keep in mind this other potentially related Epic: https://issues.redhat.com/browse/OLM-2276