bare-metal: use CLI instead of kargs for ISO path

[jlebon]

I find using the CLI more elegant. Plus, you get better progress
reporting. Plus it introduces them to the live ISO in a more natural way
(I didn't spell it out, but users can infer from the output that they've
just booted into a working FCOS instance and they can play around as
they want).

[jlebon]

Works on top of #25.

[dustymabe]

yeah I think we discussed this briefly the other day. We should probably see how this fits in with the strategy we wrote down. I do agree this looks nice. Let's talk tomorrow.

[dustymabe]

@lucab @bgilbert - in the context of what we discussed the other day, WDYT?

[dustymabe]

@jlebon - rebase?

[jlebon]

Rebased!

[dustymabe]

One possible problem with this approach is the fact that it doesn't carry forward the 'networking kargs' into the first boot, but I think it's worth exploring. I do like this approach as it seems simple and it does encourage the user to use the live system. Ultimately, though, we should probably document both ways.

[jlebon]

Just to put this in more context, this page is the first introduction to installing on bare metal. Before going the full automated, bells-and-whistles path (with high upfront cost), we need the vanilla/manual path (with low upfront cost) that most users will be willing to work through to try out.

One possible problem with this approach is the fact that it doesn't carry forward the 'networking kargs' into the first boot, but I think it's worth exploring.

Yeah, we definitely need to document this, and the fully-automated-via-Ignition case. But I don't think we should jump straight to that.

[miabbott]

LGTM

[miabbott]

Yeah, we definitely need to document this, and the fully-automated-via-Ignition case. But I don't think we should jump straight to that.

Do we have a running list of other things like this we'd like to get documented?

[lucab]

From my notes, I think we wanted to keep these cases:

1. simple case via kargs (same node)
2. simple case via container (for arbitrary disks/nodes)
3. complex case via Ignition

If we keep kargs and we add this on top, we have 1&2 covered. Thus, I'd probably rework this PR to introduce two sections, and have content in both.
(We can show direct CLI invocation or via podman, as you wish)

[dustymabe]

From my notes, I think we wanted to keep these cases:

1. simple case via kargs (same node)

2. simple case via container (for arbitrary disks/nodes)

3. complex case via Ignition

If we keep kargs and we add this on top, we have 1&2 covered. Thus, I'd probably rework this PR to introduce two sections, and have content in both.
(We can show direct CLI invocation or via podman, as you wish)

Slight proposed change:

We only document one way to install here and create a dedicated page for "other ways to install". Here we document the "interactive coreos-installer via Live ISO" method. On the other page we document:

1. simple case via kargs (same node)
   • for Live ISO
   • for PXE (automation)
2. simple case via container (for arbitrary disks/nodes)
3. complex case via Ignition

[jlebon]

We only document one way to install here and create a dedicated page for "other ways to install". Here we document the "interactive coreos-installer via Live ISO" method. On the other page we document:

Yup, makes sense to me overall.

What I'm questioning is the value of documenting the kargs via live ISO path. If it's not automated, then why not use the CLI? Or is it possible to use the live ISO in an automated fashion in some situations? If so, we should just document the kargs in that context only (automation), just like PXE.

[dustymabe]

Or is it possible to use the live ISO in an automated fashion in some situations? If so, we should just document the kargs in that context only (automation), just like PXE.

I think it is automatable via tools like virt-install but I think you're right. We should just make the "topic" of this section about automation and mention PXE as the primary use case and leave it open to other use cases as well.

[dustymabe]

LGTM