From c0d1e1c1e53a95154447d25312f53f34a8ad3aaa Mon Sep 17 00:00:00 2001 From: Doug Hellmann Date: Wed, 3 Feb 2021 14:47:00 -0500 Subject: [PATCH] switch 'create single-node-ignition-config' to take input and use systemd Signed-off-by: Doug Hellmann --- ...le-node-installation-bootstrap-in-place.md | 87 ++++++++++++------- 1 file changed, 56 insertions(+), 31 deletions(-) diff --git a/enhancements/installer/single-node-installation-bootstrap-in-place.md b/enhancements/installer/single-node-installation-bootstrap-in-place.md index 55b9caf12a..de2f2f08c9 100644 --- a/enhancements/installer/single-node-installation-bootstrap-in-place.md +++ b/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