Merge pull request #793 from wking/libvirt-support-status

README: Consolidate supported-platform documentation

README.md

@@ -3,8 +3,8 @@
 ## Supported Platforms
 
 * AWS
-* [Libvirt with KVM](docs/dev/libvirt-howto.md)
-* OpenStack (Experimental)
+* [Libvirt with KVM](docs/dev/libvirt-howto.md) (development only)
+* OpenStack (experimental)
 
 ## Quick Start
 

docs/user/overview.md

@@ -2,7 +2,7 @@
 
 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.
+On [supported platforms](../../README#supported-platforms), 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. For other platforms or in scenarios where 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
 
@@ -21,7 +21,7 @@ The main assets generated by the installer are the Ignition Configs for the boot
   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.
+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 platforms.
 
 [ignition]: https://github.com/coreos/ignition/blob/master/doc/getting-started.md
 
@@ -50,7 +50,3 @@ The following targets can be destroyed by the installer:
 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