Epic Goal

• simplify the process of installing a cluster from a previously prepared content mirror
• streamline the process of finishing an disconnected mirror to starting a cluster deployment referencing that mirror

Why is this important?

• There is significant amount of customer / user feedback that the overall process to get an OpenShift cluster deployed in an environment without access to registry.redhat.io or quay.io is too complex, involving many components
• part of the complexity is in getting a disconnected mirror stood up, this is covered in more detail in WRKLDS-281
• the other part of the complexity is lining up all the configuration to make the disconnected fully self-sufficient in a restricted network configuration
• configuring the installer to use a disconnected mirror is a manual process and it only covers the core system images, not the update graph, operators or sample images
• customers expect the installer to produce a fully disconnected cluster not just a partial disconnected cluster

Scenarios

1. A customer has used oc adm mirror to create a content mirror of various OpenShift artifacts (payload, operators, samples, etc) - this produced an offline bundle that consists of data stored in a registry or on disk and a set of configuration manifests that points to the various locations of data in the bundle
2. A customer wants to use openshift-install to install a disconnected cluster from that mirror by using a CLI switch pointing to pre-generated manifests that contain information about the location of the mirror registry, ImageContentSourcePolicies, CatalogSources, SampleOperator images and OpenShift Update Service graph image
3. openshift-install install would pick up the generated manifest to populate it's own configuration to use the mirror registry instead of quay.io and apply the rest of the generated manifests to put the disconnected cluster in a fully disconnected configuration

Acceptance Criteria

• openshift-install has a CLI switch that lets users point to the offline configuration (YAML manifest) created by the oc adm mirror command (WRKLDS-281)
• for a disconnected install that involves access to a mirror that contains the core release payload, operator catalogs and related operator images, sample images and the update graph image nothing needs to be done by the user beyond using above mentioned switch to deploy the cluster in a configuration where it solely relies on that mirror content
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. WRKLDS-281

Previous Work (Optional):

1. CORS-1633
2. CORS-1634
3. CORS-1678

Open questions::

1. Is it enough to just populate imageContentSources: in the installer config and put the rest of the generated YAML manifests into the manifest folder as a result of using the proposed CLI switch?

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>