docs: add initial documentation for end users

docs/user/overview.md

@@ -0,0 +1,56 @@
+# Installer Overview
+
+The OpenShift Installer is designed to help users, ranging from novices to experts, create OpenShift clusters in various environments. By default, the installer acts as an installation wizard, prompting the user for values that it cannot determine on its own and providing reasonable defaults for everything else. For more advanced users, the installer provides facilities for varying levels of customization.
+
+In [supported environments](#supported-environments), the installer is also capable of provisioning the underlying infrastructure for the cluster. It is recommended that most users make use of this functionality in order to avoid having to provision their own infrastructure. In unsupported environments or scenarios in which installer-created infrastructure would be incompatible, the installer can stop short of creating the infrastructure, and allow the user to provision their own infrastructure using the cluster assets generated by the installer.
+
+## Cluster Installation Process
+
+OpenShift is unique in that its management extends all the way down to the operating system itself. Every machine boots with a configuration which references resources hosted in the cluster its joining. This allows the cluster to manage itself as updates are applied. A downside to this approach, however, is that new clusters have no way of starting without external help - every machine in the to-be-created cluster is waiting on the to-be-created cluster.
+
+OpenShift breaks this dependency loop using a temporary bootstrap machine. This bootstrap machine is booted with a concrete [Ignition Config][ignition] which describes how to create the cluster. This machine acts as a temporary control plane whose sole purpose is launching the rest of the cluster.
+
+The main assets generated by the installer are the Ignition Configs for the bootstrap, master, and worker machines. Given these three configs (and correctly configured infrastructure), it is possible to start an OpenShift cluster. The process for bootstrapping a cluster looks like the following:
+
+  1. The bootstrap machine boots and starts hosting the remote resources required for the master machines to boot.
+  2. The master machines fetch the remote resources from the bootstrap machine and finish booting.
+  3. The master machines use the bootstrap node to form an etcd cluster.
+  4. The bootstrap node starts a temporary Kubernetes control plane using the newly-created etcd cluster.
+  5. The temporary control plane schedules the production control plane to the master machines.
+  6. The temporary control plane shuts down, yielding to the production control plane.
+  7. The bootstrap node injects OpenShift-specific components into the newly formed control plane.
+  8. The installer then tears down the bootstrap node.
+
+The result of this bootstrapping process is a fully running OpenShift cluster. The cluster will then download and configure remaining components needed for the day-to-day operation, including the creation of worker machines in supported environments.
+
+[ignition]: https://github.com/coreos/ignition/blob/master/doc/getting-started.md
+
+## Key Concepts
+
+While striving to remain simple and easy to use, the installer allows many aspects of the clusters it creates to be customized. It is helpful to understand certain key concepts before attempting to customize the installation.
+
+### Targets
+
+The OpenShift Installer operates on the notion of creating and destroying targets. Similar to other tools which operate on a graph of dependencies (e.g. make, systemd), each target represents a subset of the dependencies in the graph. The main target in the installer creates a cluster, but the other targets allow the user to interrupt this process and consume or modify the intermediate artifacts (e.g. the Kubernetes manifests that will be installed into the cluster). Only the immediate dependencies of a target are written to disk by the installer, but the installer can be invoked [multiple times](#multiple-invocations).
+
+The following targets can be created by the installer:
+
+- `install-config` - The install config contains the main parameters for the installation process. This configuration provides the user with more options than the interactive prompts and comes pre-populated with default values.
+- `manifests` - This target outputs all of the Kubernetes manifests that will be installed on the cluster.
+- `ignition-configs` - These are the three Ignition Configs for the bootstrap, master, and worker machines.
+- `cluster` - This target provisions the cluster by invoking a locally-installed Terraform.
+
+The following targets can be destroyed by the installer:
+
+- `cluster` - This destroys the created cluster and its associated infrastructure.
+- `bootstrap` - This destroys the bootstrap infrastructure.
+
+### Multiple Invocations
+
+In order to allow users to customize their installation, the installer can be invoked multiple times. The state is stored in a hidden file in the target directory and contains all of the intermediate artifacts. This allows the installer to pause during the installation and wait for the user to modify intermediate artifacts.
+
+For example, if changes to the install config were desired (e.g. the number of worker machines to create), the user would first invoke the installer with the `install-config` target: `openshift-install create install-config`. After prompting the user for the base parameters, the installer writes the install config into the target directory. The user can then make the desired modifications to the install config and invoke the installer with the `cluster` target: `openshift-install create cluster`. The installer will consume the install config from disk, removing it from the target directory, and proceed to create a cluster using the provided configuration.
+
+## Supported Environments
+
+  - AWS