Customer Problem

Customers mirroring Operator Catalog content for OpenShift in disconnected environments today are downloading hundreds of GBs of data and thousands of container image which is lengthy, costs a lot of storage and is error prone. The only way to cut it down is to hand select Operators which is hard and comes at the expense of explorative use and upsell potential of Operators the customer doesn’t use today.
  

Epic Goal

 * Reduce the amount of data to download to initially mirror disconnected catalogs
 * Reduce the amount of data to keep a mirrored catalog updated on regular basis
 * Increase the speed to get a catalog mirrored

Why is this important?

 * Mirroring the entire redhat-operators catalogs downloads 3100+ images which translates to 220+ GB diskspace consumed
 * this makes the initial mirror very slow and sneaker-net'ing the data across an airgap hard
 * pruning the catalog by operator (package) name is too coarse and in the long-run will prevent adoption of new Operators
 * pruning the catalog by operator platform architecture (x86_64 vs. s390x) is not possible because it changes digests of bundles and Operator images which breaks disconnected clusters (it's also not clear what the actual % of savings are in volume for the majority of the customers being on x86_64)
 * customers have no easy way to select particular versions and/or channels to be mirrored

Scenarios

 # A customer wants to install a disconnected OCP cluster and wants to initially mirror the default catalogs
 # A customer starting with a disconnected cluster may only be interested in the latest version of the Operators (in all channels) to be mirrored
 # A customer may only be interested in a specific version of a specific Operator to be mirrored
 # A customer may only be interested in a specific channel of a specific Operator to be mirrored
 # Whatever customers are deciding to base filtering/pruning a catalog upon needs to work at day 2 as well, when an existing mirrored catalog is used as the basis to only mirror incremental changes
 # customers need to be able to continuously mirror a catalog over time, so it needs to be trivial to automate
 # Customers want to use mirrored Operators that have dependencies on other Operators

Acceptance Criteria

 * The code logic created here is in the form of a shared library so that it can be used in oc and opm respectively
 * For the target release, the filter features should be exposed on opm first
 * CI - MUST be running successfully with tests automated
 * Release Technical Enablement - Provide necessary release enablement details and documents.
 * ...

Dependencies (internal and external)

 # .

Previous Work (Optional):

 # The filtering criteria proposed in this epic are meant to support the following UX describe for a new oc adm mirror command here: https://docs.google.com/presentation/d/1-fnbX57YlKze4NJ08YnS5yDqa7j3dbhjajQHUlGFGuM/edit?skip_itp2_check=true&pli=1#slide=id.gcbc2594f6b_0_2297
 # The tracking oc enablement is https://issues.redhat.com/browse/WRKLDS-281

Open questions::

 # …

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>