Uploaded image for project: 'OpenShift Workloads'
  1. OpenShift Workloads
  2. WRKLDS-281

Simplified disconnected mirroring with oc


    • Disconnected Mirroring UX
    • False
    • False
    • To Do
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined

      Epic Goal

      • Simplify the process of creating a disconnected mirror
      • Simplify the process of selecting a subset of available content to mirror
      • Converge on a single oc subcommand to mirror various kind of offline data
      • Updates to disconnected mirrors on Day 2

      Why is this important?

      • The mirroring process today is complicated due to a variety of content types that customers need to mirror to gain a fully disconnected experience
      • differing tooling is used to obtain different types of content (OCP Release Payload vs. Operator Catalogs vs. Sample Images vs. Cincinnati Graph data) leading to a fragmented UX
      • having a disconnected mirror is a pre-requisite for a substantial portion our customers (>30%) that are required to run OCP without direct internet access
      • a lot of customers prefer local mirrors even when clusters are technically connected
      • creating the disconnected mirror is still the at the heart of many customer support interaction and escalations


      1. Customers can use a single oc subcommand as the central CLI entry point to mirror all supported offline data (Release PayLoad, Operator Catalogs, Samples Images)
      2. Customers can use a set of simple CLI switches to the above oc subcommand to coarsely select or unselect which content types to mirror to speed up the download process
      3. Customers can use a control file the allows for more granular selection of content to mirror to reduce the amount of CLI switches
      4. Customers also use the oc subcommand to discover what content is available to help with selecting which OCP releases, OperatorHub Catalogs, OperatorHub Operators, Sample images to mirror

      Acceptance Criteria

      • oc provides an easy to approach CLI UX by inferring as much data as possible instead of mandatory CLI switches (infer OCP version from oc version
      • oc allows to mirror the selected set of content to an arbitrary registry or to a local disk location on the machine it executed on, creating the so call offline bundle
      • oc allows the namespace(s) in the target registry to be configurable
      • oc generates all YAML manifests that are required to configure a disconnected OpenShift cluster for offline use in a central location (ImageContentSourcePolicies, CatalogSources, patches for Sample Operators)
      • oc command line can be used a part of a system cron job to refresh the disconnected mirror regularly
      • the CLI has a switch to turn off release payload mirroring entirely in which case all of the above is ignored
      • the CLI will expect registry credentials (both for the (local) target registry as well as the release image (source) registry) in the default credentials location of podman and docker ($XDG_RUNTIME_DIR/containers/auth.json om RHEL/CentOS/Fedora)
      • the CLI will error out immediately if any of the release images fail to be pulled from the source registry
      • the CLI will error out immediately if any of the release images fail to be pushed to the (local) target registry
      • Ability to gather and bundle all the necessary OpenShift content in a single operation
      • Ability to push bundle to a local container image registry used for the installation
      • the CLI will probe both registries before doing any work by attempting to login using the existing credentials and fall back to user input of username and password if this fails, the CLI will error out if any of the interactively provided credentials fail to authenticate

      Dependencies (internal and external)

      1. ...

      Related Work:

      1. Disconnected Mirroring Improvement Proposal
      2. Fake Readme: https://hackmd.io/@dmesser/oc-adm-mirror

      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: https://url.corp.redhat.com/WRKLDS-281
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            DanielMesser Daniel Messer
            DanielMesser Daniel Messer
            ying zhou ying zhou
            4 Vote for this issue
            35 Start watching this issue