Add "RHCOS Ignition Fail to Live"

[darkmuggle]

Proposal to change RHCOS to support a "fail to a live root", to drop UPI installed platforms into an interactive recovery console.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: darkmuggle
To complete the pull request process, please assign joelanford
You can assign the PR to them by writing /assign @joelanford in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[darkmuggle]

/cc @miabbott @cgwalters @ashcrow @jlebon @crawford

[ashcrow]

Remove .

[ashcrow]

I think this is continuing from previous fragment.

[miabbott]

Notes from an internal discussion around the proposal - https://hackmd.io/JUzhpTJaRtCD0LdJNaOsHQ

[cgwalters]

Notes from an internal discussion around the proposal - https://hackmd.io/JUzhpTJaRtCD0LdJNaOsHQ

Awesome, thanks a ton for taking these notes and posting them. I think it's critically important that we continually fight the tendency to discuss and make decisions behind the RHT firewall and instead behave as much as possible as part of a collaborative FOSS project.

A good perspective on this is this blog post about Rust and the "core team".

In particular:

No New Rationale: decisions must be made only on the basis of rationale already debated in public (to a steady state)

So if we didn't post about it publicly, we shouldn't be making any decisions based on it.

[darkmuggle]

We don't have consensus yet. Another model was proposed that may supersede this idea.
/hold

[miabbott]

s/Azure/Hyper-V/

[cgwalters]

OK so Dusty's suggestion is basically "Just use the Live ISO" even for e.g. the VMWare case which is cool because we're already on track to ship the Live ISO so there'd be nothing new at all to ship for "give me something to boot to a console where I can generate a network and Ignition config".

This also resolves concerns raised in the meeting about making Ignition failures explicit etc. because we aren't changing how the non-Live-ISO boots work at all.

The only detail though is we need to handle networking in the no-config case.

[darkmuggle]

I'm not familiar with enough with the installer ISO to flesh out @dustymabe's idea. And I'm not sure the notes captured the nuance of it.

[miabbott]

I think we can provide this "fail to live" functionality as well as providing the Live ISO to do similar kinds of configuration. One does not appear to preclude the other.

I'd recommend we continue to pursue this proposal, as we have received early feedback from folks in the field that it is desirable.

[cgwalters]

It's really simple, for vmware or bare metal:

• Download pristine -live.iso
• Boot from it (image to USB, add as device in vmware, add via IMPI on metal, etc.)
• You get auto-logged into a live CoreOS system without network
• Generate an Ignition config however you like, plus e.g. kernel cmdline arguments for network
• Run coreos-installer install -i /path/to/config.ign --firstboot-args <network kargs> /dev/whatever

All of this exists today and works except for the last issue mentioned in #256 (comment)

What feedback from the field isn't covered by this?

[cgwalters]

That said, linking this to the "nmtui" thing - we should ship that as part of the live ISO, and then have support for synthesizing the network config into kernel args - or special support for dropping network config into the initramfs.

[darkmuggle]

In follow up discussions, this idea has been superseded for an installer-based path that would handle injecting setting the network configuration.

[miabbott]

It's really simple, for vmware or bare metal:

* Download pristine `-live.iso`

* Boot from it (image to USB, add as device in vmware, add via IMPI on metal, etc.)

* You get auto-logged into a live CoreOS system without network

* Generate an Ignition config however you like, plus e.g. kernel cmdline arguments for network

* Run `coreos-installer install -i /path/to/config.ign --firstboot-args <network kargs> /dev/whatever`

All of this exists today and works except for the last issue mentioned in #256 (comment)

Do we need a separate enhancement to cover the behavior change of dropping to a live system?

[cgwalters]

Do we need a separate enhancement to cover the behavior change of dropping to a live system?

That's just it - there isn't a behavior change, it's what the Live ISO you can download from e.g. https://getfedora.org/coreos/ does today (and will for RHCOS too).

[miabbott]

That's just it - there isn't a behavior change, it's what the Live ISO you can download from e.g. https://getfedora.org/coreos/ does today (and will for RHCOS too).

So any enhancement required would really be #210

[darkmuggle]

Per https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-25/fedora_coreos_meeting.2020-03-25-16.31.html
This idea is done.

[cgwalters]

So any enhancement required would really be #210

Well...the basics are that yes. It avoids the "catch the grub prompt" required in this blog.

We could call it done there. But I think there's a lot more we could do beyond solving the grub prompt problem, including more easily generating those kargs, and dealing with fetching the base Ignition configs.

And all that stuff could be a separate enhancement or we could append it to the existing one.