Epic Goal

• As an OpenShift infrastructure owner, I need a way to create my first on-premises cluster.
• As an OpenShift infrastructure owner using a platform that is not formally supported by Red Hat, I need the ability to install OpenShift that is easier than the fully manual UPI process.

Why is this important?

• Installing OpenShift has to be as simple as possible with as few requirements as reasonably possible. A bootable, ephemeral image based on the assisted-installer technology developed by the ecosystem team is one way to permit installing OpenShift clusters requiring access only to the hardware dedicated to the new cluster (as opposed to requiring a dedicated provisioning node or even an external service).

Scenarios

1. The user has only access to the target nodes that will form the cluster and will boot them with the image presented locally via a USB stick. This scenario is common in sites with restricted access such as government infra where only users with security clearance can interact with the installation, where software is allowed to enter in the premises (in a USB, DVD, SD card, etc.) but never allowed to come back out. Users can't enter supporting devices such as laptops or phones.
2. The user has access to the target nodes remotely to their BMCs (e.g. iDrac, iLo) and can map an image as virtual media from their computer. This scenario is common in data centers where the customer provides network access to the BMCs of the target nodes.
3. We cannot assume that we will have access to a computer to run an installer or installer helper software.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• 
  Take the functionality of the fleeting prototype and integrate it into the openshift/installer repo as described in https://github.com/openshift/enhancements/pull/1067

Open questions:

1. An image generator has been identified as a possible requirement for this flow. If required, should it be part of the installer image and not an artifact on its own? 
2. What’s the envisioned workflow during the installation when dedicated node images need to be created?
3. How should we distribute this new installer solution?
4. ARM Considerations - TBD

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>

References

• Bootable Ephemeral Installer Image for Disconnected Cluster 0 Deployments