# Notes on assisted-installer/openshift-install dependencies

The context for this is the [single-node deployment with bootstrap-in-place](https://github.com/openshift/enhancements/pull/565) enhancement.

**Q: How do the assisted installations use the Ignition files generated by openshift-install to bootstrap an installation?**

**A:**

Before the installation bootstrap begins, the required nodes are running and the assisted agent is awaiting commands from the assisted service.

The agent on the bootstrap/master machine receives a command from the assisted service to run the `assisted-installer` binary with the `bootstrap` role.

The assisted-installer downloads the `bootstrap.ign` file from the service and uses the [machine-config-daemon "once from" mode](https://github.com/openshift/machine-config-operator/blob/master/docs/OnceFrom.md) to execute the Ignition file - i.e. to extract its files and systemd units to disk. This machine-config-daemon mode exists to support the "bring your host" model.

The assisted-installer then starts the systemd units required for the bootstrap control plane.

The assisted-installer also defines a run-once pod that hosts an assisted-installer controller which completes some post-install configuration and sends a status update to the assisted service.

Once the required number of master nodes (usually 2) have joined, and the bootstrap process has finished, then the assisted-installer proceeds to "pivot" the bootstrap node by downloading and installing the `master.ign` and, finally, rebooting.

**Q: What internal installer implementation details does the assisted installer depend on?**

*(i.e. what installer implementation details cannot be changed without requiring changes to the assisted-installer?)*

**A:**

Looking at openshift/assisted-installer/src/installer/installer.go

1. That `bootstrap.ign` contains these systemd services: bootkube.service, approve-csr.service, progress.service
2. That those services are the only services required to launch the bootstrap control plane
3. The existence of `/opt/openshift/.bootkube.done` indicates that the bootstrap process has completed

**Q: What new dependencies on implementation details will bootstrap-in-place introduce?**

**A:**

Assisted installs using the bootstrap-in-place workflow uses the `bootstrap-in-place-for-live-iso.ign` Ignition config generated by openshift-install in a similar way to how it uses the regular `bootstrap.ign`. However, instead of downloading the `master.ign` to "pivot" to, it instead uses the "enriched" master Ignition generated by bootkube.

1. That bootkube will output the single-node Ignition file at `/opt/openshift/master.ign` and not run coreos-installer
2. That the single-node Ignition file can be merged with a master Ignition file from the assisted service?

**Q: Why can assisted installs not have `bootkube.service` run the `coreos-installer`?**

**A:**

After generating the master Ignition file, and before rebooting, the assisted installer uploads logs and sends a status update to the assisted service. Doug's suggestion in the enhancement is for these steps to move into another systemd service installed by the assisted installer.

It also merges the enriched Ignition file with the master Ignition file downloaded from the assisted service.

It also has specifies its own arguments to `coreos-installer`. The user can ask for [a set of supported configurations](
https://github.com/openshift/assisted-service/blob/c43b027de9d6c743dc8f1f6f63f81f957215239d/internal/host/hostutil/host_utils.go#L77) via the REST API.