docs: update docs for pre-cluster stage

The ignition-configs stage has been deprecated and replaced with
the node-config, bootstrap-config, and pre-cluster stages. The docs
are updated to reflect those changes.

docs/user/aws/install_upi.md

@@ -10,7 +10,7 @@ The machines will be started manually. Therefore, it is required to generate the
 and store them for later steps.
 
 ```console
-$ openshift-install-linux-amd64 create ignition-configs
+$ openshift-install-linux-amd64 create pre-cluster
 ? SSH Public Key /home/user_id/.ssh/id_rsa.pub
 ? Platform aws
 ? Region us-east-1
@@ -24,12 +24,16 @@ After running the command, several files will be available in the directory.
 ```console
 $ tree
 .
-├── auth
-│   └── kubeconfig
-├── bootstrap.ign
-├── master.ign
-├── metadata.json
-└── worker.ign
+└── pre-cluster
+    ├── auth
+    │   ├── kubeadmin-password
+    │   └── kubeconfig
+    ├── bootstrap.ign
+    ├── master.ign
+    ├── metadata.json
+    └── worker.ign
+
+2 directories, 6 files
 ```
 
 ## Create/Identify the VPC to be Used

docs/user/customization.md

@@ -198,7 +198,7 @@ For example:
 
 ## OS Customization (unvalidated)
 
-In rare circumstances, certain modifications to the bootstrap and other machines may be necessary. The installer provides the "ignition-configs" target, which allows arbitrary modification to the [Ignition Configs][ignition] used to boot these machines. Note that there is currently no validation on the modifications that are made, so it is possible that the changes will result in a non-functioning cluster.
+In rare circumstances, certain modifications to the bootstrap and other machines may be necessary. The installer provides the "bootstrap-config" and "node-config" targets, which allows arbitrary modification to the [Ignition Configs][ignition] used to boot these machines. Note that there is currently no validation on the modifications that are made, so it is possible that the changes will result in a non-functioning cluster.
 
 An example `worker.ign` is shown below. It has been modified to increase the HTTP timeouts used when fetching the generated worker config from the cluster. This isn't likely to be useful, but it does demonstrate what is possible.
 

docs/user/metal/install_upi.md

@@ -170,20 +170,23 @@ NOTE: The filename for `install-config` in the `INSTALL_DIR` must be `install-co
 
 ### Invoking the installer to get Ignition configs
 
-Given that you have setup the `INSTALL_DIR` with the appropriate `install-config`, you can create the Ignition configs by using the `create ignition-configs` target. For example,
+Given that you have setup the `INSTALL_DIR` with the appropriate `install-config`, you can create the Ignition configs by using the `create pre-cluster` target. For example,
 
 ```console
-$ openshift-install --dir test-bare-metal create ignition-configs
+$ openshift-install --dir test-bare-metal create pre-cluster
 INFO Consuming "Install Config" from target directory
 $ tree test-bare-metal
 test-bare-metal
-├── auth
-│   └── kubeconfig
-├── bootstrap.ign
-├── master.ign
-└── worker.ign
-
-1 directory, 4 files
+└── pre-cluster
+    ├── auth
+    │   ├── kubeadmin-password
+    │   └── kubeconfig
+    ├── bootstrap.ign
+    ├── master.ign
+    ├── metadata.json
+    └── worker.ign
+
+2 directories, 6 files
 ```
 
 ## Getting OS related assets for machines

docs/user/overview.md

@@ -38,9 +38,11 @@ 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.
 - `manifest-templates` - These are the unrendered Kubernetes manifest templates that feed the `manifests` target.
     This target is [unstable](versioning.md).
+- `node-config` - This target generates the Ignition Configs for the master and worker machines.
 - `manifests` - This target outputs all of the Kubernetes manifests that will be installed on the cluster.
     This target is [unstable](versioning.md).
-- `ignition-configs` - These are the three Ignition Configs for the bootstrap, master, and worker machines.
+- `bootstrap-config` - This target generates the Ignition Config for the bootstrap machine.
+- `pre-cluster` - This contains read-only versions of asset files useful just before creating the cluster. This includes the Ignition Configs for the bootstrap, master, and worker machines; the kubeconfig; the kube admin password; and the metadata for identifying the cluster. The files are placed under the pre-cluster directory in the asset directory.
 - `cluster` - This target provisions the cluster and its associated infrastructure.
 
 The following targets can be destroyed by the installer:

docs/user/versioning.md

@@ -4,7 +4,9 @@ The installer uses [Semantic Versioning][semver] for its user-facing API.
 Covered by the versioning are:
 
 * `openshift-install [options] create install-config`, which will always create `install-config.yaml` in the asset directory, although the version of the generated install-config may change.
-* `openshift-install [options] create ignition-configs`, which will always create `bootstrap.ign`, `master.ign`, and `worker.ign` in the asset directory, although the content of the generated files may change.
+* `openshift-install [options] create node-config`, which will always create `master.ign` and `worker.ign` in the asset directory, although the content of the generated files may change.
+* `openshift-install [options] create bootstrap-config`, which will always create `bootstrap.ign` in the asset directory, although the content of the generated files may change.
+* `openshift-install [options] create pre-cluster`, which will always create `boostrap.ign`, `master.ign`, `worker.ign`, `metadata.json`, `auth/kubeconfig`, and `auth/kubeadmin-password` in the `pre-cluster` directory in the asset directory, although the contents of the generated files may change.
 * `openshift-install [options] create cluster`, which will always launch a new cluster.
 * `openshift-install [options] destroy bootstrap`, which will always destroy any bootstrap resources created for the cluster.
 * `openshift-install [options] destroy cluster`, which will always destroy the cluster resources.