switch 'create single-node-ignition-config' to take input and use sys…

…temd

Signed-off-by: Doug Hellmann <[email protected]>

enhancements/installer/single-node-installation-bootstrap-in-place.md

@@ -152,12 +152,12 @@ kubernetes operations run during bootstrapping.
 
 We will add a new `create single-node-ignition-config` command to the
 installer to create the `bootstrap-in-place-for-live-iso.ign` Ignition
-config.  This new target will not output `master.ign` and `worker.ign`
+config.  This new target will *not* output `master.ign` and `worker.ign`
 files.
 
-This Ignition config will have a different `bootkube.sh` from the
-default bootstrap Ignition. In addition to the standard rendering
-logic, the modified script will:
+The `bootstrap-in-place-for-live-iso.ign` Ignition config will have a
+different `bootkube.sh` from the default bootstrap Ignition. In
+addition to the standard rendering logic, the modified script will:
 
 1. Start `cluster-bootstrap` without required pods by setting `--required-pods=''`
 2. Run `cluster-bootstrap` with the `--bootstrap-in-place` option.
@@ -166,26 +166,37 @@ logic, the modified script will:
    kubernetes resources, and the bootstrap etcd database snapshot to
    create a new Ignition config for the host.
 
-In order to successfully complete the installation, the user must tell
-`coreos-install` where to write the operating system image on the
-host's local storage. It may be necessary to provide other inputs to
-`coreos-install` at the same time (network addresses, etc.), and we
-have not yet completed the investigation and experimentation work
-required to design a supportable API for the complex details that may
-be needed. Therefore, to unblock progress on the bootstrap-in-place
-feature, we will temporarily treat installing the operating system as
-a manual step. Users running the OpenShift installer by hand will need
-to login to the host via `ssh` and run `coreos-install`, passing the
-appropriate arguments. Users relying on integration with Hive and the
-assisted installer for multi-cluster management will not need to
-perform this step by hand, since the agent driven by the assisted
-installer service runs `coreos-install` already. The installer and
-edge teams will work on this area further during this next release
-cycle, and use another enhancement proposal to describe the
-implementation of an API to replace the manual step.
-
-After the user runs the `coreos-install` and the RHCOS image is
-written to disk, they also need to reboot the host.
+In order to successfully complete the installation, we must know
+where to write the operating system image on the host's local
+storage. Initially this information will be passed as a single value
+in the `install-config.yaml`, using a schema like
+
+```yaml
+coreOSInstallation:
+  rootDevice: '/dev/vda'
+```
+
+We expect this section of the `install-config.yaml` schema to evolve
+and add more fields. The precise name of the new section and this
+first field will be worked out on the pull request to update
+installer. Future updates, to pass additional data to the installer or
+to support multiple values for multiple hosts, will be addressed in a
+separate enhancement.
+
+The new `coreOSInstallation` section and the field with the root
+device name will always be required for the `create
+single-node-ignition-config`. If the details are omitted from the
+`install-config.yaml`, the installer will report an error and exit.
+
+Using the data from the `coreOSInstallation` section, the OpenShift
+installer will add a new `systemd` unit to the
+`bootstrap-in-place-for-live-iso.ign` Ignition config to run
+`coreos-install` to install the operating system onto the host's local
+storage and reboot the host. This service will run when a single-node
+cluster is bootstrapping without the assisted installer, but will be
+skipped when the assisted installer is used so that we can retain the
+existing features to monitor progress and control the OS installation
+more completely.
 
 #### Cluster-bootstrap
 
@@ -378,6 +389,21 @@ and then remotely running /usr/local/bin/installer-masters-gather.sh on all mast
  on itself. The final archiving of all the logs into the home directory,
  exactly the same as /usr/local/bin/installer-gather.sh.
 
+#### Tight coupling of assisted installer and OpenShift installer implementation
+
+The assisted installer currently relies on implementation details of
+the bootstrap process to change the way clusters are created. This
+change introduces another dependency on the `bootkube.service` in the
+Ignition config generated by the installer creating another Ignition
+config during bootstrapping and placing it in
+`/opt/openshift/master.ign`. Renaming that file within the OpenShift
+installer will break the assisted installer.
+
+All of these dependencies on implementation details will be addressed
+in future enhancements, either by documenting them as APIs or by
+providing new APIs and having the assisted installer migrate to using
+those.
+
 ## Design Details
 
 ### Open Questions
@@ -614,17 +640,16 @@ We decided to add `single-node-ignition-config` target to in order to gain:
 
 ### Alternatives for managing the operating system installation step
 
-Before settling on using a manual process, we identified several
-options for installing the operating system during deployment.
+Before settling on adding a minimal set of fields to
+`install-config.yaml`, we identified several options for installing
+the operating system during deployment.
 
 1. We could give the user instructions to ssh to the host and run a
    command.
 
-   This is the option we selected. It requires additional work for
-   users running the installer by hand, and will require some changes
-   to the CI jobs for single-node deployments, but is the most
-   flexible and does not commit us to maintaining and API we have
-   rushed to design.
+   This option requires extra manual steps by the user, which is
+   likely to lead to various implementations in different environments
+   when the steps are automated.
 
 2. We could add an unsupported experimental environment variable to
    all installer builds, so that the user could pass information