OCP/Telco Definition of Done
<https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde>
Epic Template descriptions and documentation.
<https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit>
ACM-wide Product Requirements (Top-level Epics)
<https://docs.google.com/document/d/1uIp6nS2QZ766UFuZBaC9USs8dW_I5wVdtYF9sUObYKg/edit>

*<--- Cut-n-Paste the entire contents of this description into your new
Epic --->*

Epic Goal

Provide a mechanism/service to apply cluster specific attributes to a pre-installed generic OCP cluster. This service supports and enables factory workflows where OpenShift is installed on a cluster prior to installation at a specific site/location. Once installed the cluster will be given unique cluster specific attributes that need to be applied, including:

• Cluster name (FQDN)
• Networking details – IPv4/IPv6/Dual Stack, gateway, DNS, ... (NMStateConfig)
• Registry access: Pull secret, ImageContentSourcePolicy, CatalogSource
• ssh keys
• Other attributes which are configurable at cluster install time.

In addition to setting these attributes the services should perform the necessary steps to make the cluster configuration unique

• Regenerate cluster certificates, kubeconfig, kubeadmin password (as needed)
• etc

The attributes need to be supplied to the cluster in a way which supports:

• automatic registration and import with ACM (ref ACM-2252)
• zero touch provisioning
  • no admin interaction required during bringup at spoke cluster or hub cluster.
  • Pre-defining the cluster (eg ManagedCluster and other artifacts) at the hub prior to bringup of the spoke cluster is expected.

Supplying the attributes via a custom ISO image mounted as virtual media, similar to how the discovery ISO is used in full installation ZTP flow would work well for the use case.

Why is this important?

Customers deploying large numbers of clusters at the edge of the network want to improve their operational efficiency through factory workflow to pre-install OpenShift. This workflow aims to:

1. Reduce the time to deploy a cluster by eliminating the OCP installation phase once the cluster is at the site
2. Eliminate failures due to networking events (transient outages, low bandwidth, etc) during cluster bringup at site
3. Eliminate failures due to hardware issues. Pre-installing OCP at the factory assists in identifying failed hardware prior to delivery to the site.
4. Support factory installation of a large number of generic clusters which can be delivered to any site
   1. Generic clusters enable OCP installation before the specific site(s) and/or parameters are fully defined. This decouples the side definition from the server preparation.
   2. Generic clusters reduces complexity in managing inventory at the factory. A service technician can stock the truck with any (proper hardware configuration) cluster rather than identifying a specific unit to be delivered. Similarly, any truck with proper hardware can be redirected to deploy a site.

Scenarios

1. See examples above
2. Customer wants to maintain inventory of generic clusters for rapid installation at sites.
3. Customer wants faster and more reliable bringup of edge sites

Acceptance Criteria

1. A service can be added to a pre-installed generic OpenShift cluster which will accept and apply site specific attributes at initial bringup without admin intervention.
2. The service does not depend on a specific OCP installation method other than a requirement that the service be included in the installation.

Dependencies (internal and external)

Previous Work (Optional):

Open questions:

1. How is the updated/regenerated kubeconfig provided to the hub cluster and user/administrator?

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>