# Topic: Ignition Network Failure Fault Mode (Continued)
## Lead: Ben Howard
## Summary:
Bare Metal installation experience is dreadful. One potential solution was to add a TUI for user-interaction. The problem is that we need to halt boot on no networking in certain conditions (such as networking is required in order to fetch the Ignition Configuration, or even the files so requested by the config). During the investigation of potential solutions, I looked at having a separate target that would try to determine the network state, but all the potential answers seem like hacks and bolt-on changes instead of directly dealing with the problem state.

Xref https://github.com/coreos/ignition-dracut/issues/94
And https://github.com/coreos/ignition/issues/585
And https://github.com/openshift/enhancements/pull/256

### Notes:
[BenH] Potential solution - https://github.com/openshift/enhancements/pull/256
[BenH] TL;DR - if a conditions indicate there is a human in front of a console (i.e. kargs), we drop to a live system on Ignition failure where corrected changes can be provided. Only valid for network configuration + Ignition config failures. Reboot into “corrected” config.
[Ian] This excites the folks in the bare metal cases.
[Alex] This idea makes me nervous. Customers may deploy into this config and fail to remove the initial flags/conditions where later on will cause another failure to boot. The bare metal folks have been working on a dedicated discovery image.
[Colin] The first boot is entirely ephemeral except for the networking. By default, if you do nothing, you are back to the default/broken condition. After the initial reboot, the necessary flags are removed and Ignition would not run again on subsequent reboots.
[Alex] What is the expected flow for new nodes/new machines being added to the cluster?
[Colin] We need to support the automated case; done via `coreos-installer embed-ignition`. Creates customized ISO per machine. https://github.com/coreos/coreos-installer/issues/164
[Alex] The use of a discovery image allows us to skip the entire fetching of the Ignition config and skips the failure scenario
[Benjamin] How does the static networking config get relayed back to the machine from the discovery image?
[Ian] The request came from bbreard/the field. We have 3 ways to provide Ignition config (in order of popularity):
Prescriptive backchannel
Interactive access to console
Neither console/backchannel, but can customize image per image
[Ian] coreos-installer and discovery image appear to be doing the same thing
[Colin] we will have a live ISO for 4.5; if nothing is provided to the ISO, we drop to a shell.
[Dusty] the live ISO has a baked config that drops to an ephemeral system/shell
[Colin] the main use case for live systems is installing to disk. Allows for discovery of network interface naming etc
[BenH] we give the users ability to provide network information via nmtui which is then persisted to the “real” system. The intent is not to provide an ephemeral system where containers can be pulled, etc.
[Alex] After the install is completed during OCP install, if the initial Ignition fetch fails what happens?
[BenH] If network fetch fails and networking is configured, we drop to interactive console
[Alex] It was a good decision to make Ignition atomic - it either works or not. I just don’t want to lose it.
[BenH] We maintain the persistence of the network configuration via Ignition. We are not trying to get in the way of Ignition, we are trying to augment it.
[Colin] desktop systems boot to a live system where the installer is an app, whereas with kickstart systems boot to Anaconda. We are allowing for a single class of changes (networking) to be persisted to the first boot.
[BenH] If configuration changes are not encoded in Ignition, they are not persisted
[jlebon] When Ignition runs it acts on the real root; when it fails we need to make that decision before Ignition acts on that real root. There is a difference between no Ignition config and a bad Ignition config. Should we use the lack of an Ignition config as the condition to drop to the live image?
[slowrie] it was common to not provide ignition configs for providers that have a way to provide ssh keys in another way. Having no Ignition config was a valid state for CL.
[BenH] If ignition-fetch doesn’t swallow errors and we act on errors related to the Ignition URL, we should still be able to use the proposed model.
[Dusty/slowrie] no Ignition config is a supported use case for FCOS, but probably not RHCOS. Is just using the live environment a solution to this problem?
[Ian] There is a real use case for RHCOS users on bare metal to be able to boot into the installer and getting an interactive environment for configuration purposes.
[Colin/Dusty] can VMWare users just use the proposed live ISO model?
[Ian] yes, this also provides us the way to support Hyper-V. VMWare users may still use the backchannel to provide configs. Hyper-V has a terrible backchannel. And there is no backchannel for metal. All of these use cases are supported by this model.
[Colin] the live ISO requires networking, but we need to break that
[slowrie] many users treat their VMs as just bare metal instances regardless of platform
[Dusty/Colin] we need some tools in this interactive environment to make the user experience easier (i.e. filetranspiler)
**Action: need another meeting; flesh out additional details about this proposal**