Proposed title of this feature request

Achieve feature parity for recently introduced functionality for all modes of operation

Nature and description of the request

Currently there are gaps in functionality within oc mirror that we would like addressed.

1. Support oci: references within mirror.operators[].catalog in an ImageSetConfiguration when running in all modes of operation with the full functionality provided by oc mirror.

Currently oci: references such as the following are allowed only in limited circumstances:

mirror:
   operators:
   - catalog: oci:///tmp/oci/ocp11840
   - catalog: icr.io/cpopen/ibm-operator-catalog
 

Currently supported scenarios

• Mirror to Mirror

In this mode of operation the images are fetched from the oci: reference rather than being pulled from a source docker image repository. These catalogs are processed through similar (yet different) mechanisms compared to docker image references. The end result in this scenario is that the catalog is potentially modified and images (i.e. catalog, bundle, related images, etc.) are pushed to their final docker image repository. This provides the full capabilities offered by oc mirror (e.g. catalog "filtering", image pruning, metadata manipulation to keep track of what has been mirrored, etc.)

Desired scenarios
In the following scenarios we would like oci: references to be processed in a similar way to how docker references are handled (as close as possible anyway given the different APIs involved). Ultimately we want oci: catalog references to provide the full set of functionality currently available for catalogs provided as a docker image reference. In other words we want full feature parity (e.g. catalog "filtering", image pruning, metadata manipulation to keep track of what has been mirrored, etc.)

• Mirror to Disk

In this mode of operation the images are fetched from the oci: reference rather than being pulled from a docker image repository. These catalogs are processed through similar yet different mechanisms compared to docker image references. The end result of this scenario is that all mappings and catalogs are packaged into tar archives (i.e. the "imageset").

• Disk to Mirror

In this mode of operation the tar archives (i.e. the "imageset") are processed via the "publish mechanism" which means unpacking the tar archives, processing the metadata, pruning images, rebuilding catalogs, and pushing images to their destination. In theory if the mirror-to-disk scenario is handled properly, then this mode should "just work".

Below the line was the original RFE for requesting the OCI feature and is only provided for reference.

ORIGINAL REQUEST FOR LOCAL CATALOG SUPPORT

Proposed title of this feature request

Support a locally addressable filesystem representation of an operator catalog image as an input source in an ImageSetConfig

Nature and description of the request

This RFE is asking that oc-mirror accept multiple operator catalog image-representations or "types" as input via the catalog element in an ISC.

Specifically that it supports at least one local filesystem "type".

These "types" could be similar to what tools like skopeo use today (ie: docker://, oci://, dir://)

skopeo copy docker://registry.redhat.io/redhat/certified-operator-index:v4.10 oci:.

Currently oc-mirror only allows a user to specify an operator catalog image via a string which is a reference to a catalogSource container image in a container registry.

mirror:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.8

There are customer scenarios where being able to specify the catalog input to oc-mirror via an accessible filesystem path (ie: type = oci or type = dir...) provides a more streamlined customer experience.

Tomorrow, possible transport type based image representations to show concept:

mirror:
    - catalog: “docker://registry.redhat.io/redhat/redhat-operator-index:v4.8”  #whats there today
    - catalog: “oci:<relative path to accessible filesystem representation of the image >”   #possible filesystem based image representations
    - catalog: “dir:<relative path to accessible filesystem representation of the image>”
    - catalog: “tgz:<relative path to accessible filesystem representation of the image>”

In all of the input types, a catalog image contains a specific version of opm code that "knows" how to serve the grpc interface and "knows" how to interact with the "File Based Catalog" that was packaged in the image when it was built.

The oc-mirror tooling accepts the container image as input and will only modify the "FBC" layers of this image. It preserves the layers that represent the specific version of opm that "works", by only modifying the "backend/fbc" layers of this image.

oc-mirror does not have to concern itself with making sure the image it produces is using the "right" opm binary. It just uses what was already present in the image.

The core logic of oc-mirror should remain the same once the input has been loaded based on it's type.