Epic Goal

• GA of oc mirror
• Additional lifecycle capabilities for long running mirrors
• Usability optimizations

Why is this important?

• oc mirror is introduced as Tech Preview in OCP 4.10
• customers need additional day capabilities beyond just adding content, e.g. removing content to avoid ever growing registry consumption
• performance optimizations are required on top of what has been released in Tech Preview, e.g. reduction of local disk consumption which would otherwise become a long-term concern

Scenarios

1. Customers can use the oc utility to delete unwanted OCP release images in the target registry
2. Customers can use the oc utility to delete unwanted Operator packages in the target registry
3. Customers can use the oc utility to directly stream downloaded content directly into the target registry without storing on local disk
4. Customers can mirror between disconnected registries using the oc utility
5. The oc utility works seamlessly with a locally running registry
6. The oc utility supports creating (or mirroring a public [if available]) OSUS graph image
7. The oc utility supports mirroring all common OpenShift CLI utilities
8. The oc utility uses a custom agent string when interacting with registries so that pull statistics can be obtained for public registries serving content
9. The oc utility declarative file format allows to target specific Operator and OCP versions and the required in-between releases to be mirrored will be determined automatically

Acceptance Criteria

• Customers can use the utility without the requirement of having local disk capacity available - done
• Customers can delete OCP release payloads and Operator packages that aren't required anymore - in-progress
• Customers can use the oc utility to mirror between two different air-gapped environments - cannot accommodate in 4.11 
• oc subcommand by default assumes a local, trusted, TLS-secured registry available at the public host name of machine it is executed on so that it targets a local registry by default, using a default value for the registry - cannot accommodate in 4.11
• oc subcommand creates the necessary OSUS configuration to references the generated / mirrored OSUS image - done 
• oc subcommand creates cincinnati manifest needed for OSUS and the release sig configmap - in-progress
• oc subcommand mirrors by default all common CLI tools are also mirrored: oc, openshift-install, opm, helm, openshift-mirror-registry - cannot accommodate in 4.11
• to mirror the release payload the CLI can run without any specific switches in which case it will assume the following:
  • a locally available registry on port 443 - cannot accommodate in 4.11
  • existing credentials for this local registry - done
  • existing pull secret for the release image registry - done
  • the OCP release version is the version of the oc utility - cannot accommodate in 4.11
  • the target registry namespace / organization is openshift-<release-version> where release-version is the OCP release version to mirror payload for - done
  • the release architecture is the architecture of the oc binary, otherwise x86_64 is the default - in-progress, partially accommodated
  • the source to download the release images is the openshift-release-dev organization from quay.io - done 
• oc uses a custom agent when interacting with registries in the form of  ‘User-Agent: ocmirrorX.X/X.X.X…..’ instead of 'User-Agent: oc4.7/4.7.0 (linux/amd64) kubernetes/2513fdb' - in progress

Dependencies (internal and external)

Related Work:

1. WRKLDS-281
2. Disconnected Mirroring Improvement Proposal

Open questions::

1. …

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>