Epic Goal

• Mirror to mirror operations and custom mirroring flows required by IBM CloudPak catalog management

Why is this important?

• IBM needs additional customization around the actual mirroring of images to enable CloudPaks to fully adopt OLM-style operator packaging and catalog management
• IBM CloudPaks introduce additional compute architectures, increasing the download volume by 2/3rds to day, we need the ability to effectively filter non-required image versions of OLM operator catalogs during filtering for other customers that only require a single or a subset of the available image architectures
• IBM CloudPaks regularly run on older OCP versions like 4.8 which require additional work to be able to read the mirrored catalog produced by oc mirror

Scenarios

1. Customers can use the oc utility and delegate the actual image mirror step to another tool
2. Customers can mirror between disconnected registries using the oc utility
3. The oc utility supports filtering manifest lists in the context of multi-arch images according to the sparse manifest list proposal in the distribution spec

Acceptance Criteria

• Customers can use the oc utility to mirror between two different air-gapped environments
• Customers can specify the desired computer architectures and oc mirror will create sparse manifest lists in the target registry as a result

Dependencies (internal and external)

• Sparse Manifest List Support in Red Hat Quay (PROJQUAY-3114)

Previous Work:

1. WRKLDS-369
2. Disconnected Mirroring Improvement Proposal

Related Work:

1. https://github.com/opencontainers/distribution-spec/pull/310
2. https://github.com/distribution/distribution/pull/3536
3. https://docs.google.com/document/d/10ozLoV7sVPLB8msLx4LYamooQDSW-CAnLiNiJ9SER2k/edit?usp=sharing