coreos / coreos-installer

Installer for CoreOS disk images
https://coreos.github.io/coreos-installer/
Apache License 2.0
222 stars 93 forks source link

Don't default to FCOS #1225

Open runcom opened 1 year ago

runcom commented 1 year ago

Feature Request

Reporting something which should be discussed here I think, from @cgwalters (a couple edits to make it more generic):

As coreos-installer is now used by other distros (such as RHEL for Edge), I think it doesn't make sense to have "coreos-installer" default to installing Fedora CoreOS - at least when built for other distros (e.g. RHEL).

We've seen at least a few situations where people trying to use coreos-installer for RHEL CoreOS/OCP somehow get defaulted to trying to install FCOS which has to be from their PoV extremely surprising.

(I'd bikeshed that we should introduce a wrapper binary fedora-coreos-installer that is literally just:

#!/bin/bash
exec coreos-installer --distro fcos

or so, then ship that in Fedora too.

Desired Feature

Other Information

bgilbert commented 1 year ago

See previous discussion in this BZ. Quoting myself from comment 9:

Anyone who accidentally installs FCOS is not using the program correctly; they're failing to specify the image they want to install. (Or, in some of the historical cases, we've broken something in the OS image.) I agree that that's confusing, and should be improved, but it's basically a papercut. You're proposing to fix that papercut by actively breaking FCOS users (in some flows) who are using the program as intended. I agree that we probably need to do that, but we need a proper deprecation period and we need to do it consistently in all flows.

The wrapper script you're proposing doesn't avoid breaking existing use cases, and isn't easier to invoke than coreos-installer install --distro fcos, so I don't really think it helps.

cgwalters commented 1 year ago

I think basically:

Also tangentially related, bootc solves this because the thing being run is a container which installs itself, so the install command inherently already contains a distribution reference.

bgilbert commented 1 year ago

unless we're running on FCOS

No, we need to do it everywhere, otherwise we're not actually deprecating the behavior. I'd also argue for advance notice via coreos-installer release notes and maybe a coreos-status post.

cgwalters commented 1 year ago

Apparently I was confused and it's worse than I thought; --distro only exists in coreos-assembler. I had to dig this up but we had a related debate over here https://github.com/coreos/stream-metadata-rust/pull/3

bgilbert commented 1 year ago

There is also #26. We never added --distro because RHCOS doesn't have any reasonable defaults; coreos-installer would need to know what bootimage the cluster was installed from. I don't know the R4E semantics; is there something like stream metadata we could use to find the current install image?

Strictly speaking, though, the change in this issue still makes sense even if fcos is the only option for --distro.

cgwalters commented 1 year ago

We never added --distro because RHCOS doesn't have any reasonable defaults; coreos-installer would need to know what bootimage the cluster was installed from.

But our flow is often used to create a cluster; so we can't default to being driven from an existing cluster. The obvious thing here seems to me to have e.g. --distro rhcos --stream 4.13 for example.

bgilbert commented 1 year ago

But our flow is often used to create a cluster; so we can't default to being driven from an existing cluster.

Right, that's the problem: there's no one-size-fits-all solution. New cluster installs could use stream metadata, but I don't see a way to provide --distro rhcos --stream 4.13 without also providing a major footgun for UPI users expanding an existing cluster.

cgwalters commented 1 year ago

see a way to provide --distro rhcos --stream 4.13 without also providing a major footgun for UPI users expanding an existing cluster.

I think this is the fundamental disagreement; I think the only viable way to do this is to not require --distro (or --stream) in cases that already implicitly do the correct thing for both FCOS and RHCOS, which is basically (IIUC):

Which are how UPI installs work today right? So they'd continue to work.

bgilbert commented 1 year ago

No, I agree that the osmet case shouldn't require the option. But in that case, we don't need --distro rhcos --stream 4.13 either, since the user has already told us what to install by choosing the correct boot media.

So in essence we should require one of: osmet, --image-url, --image-file, or --distro. The reason we need a careful deprecation period is to avoid surprises in the "installing FCOS with a coreos-installer container" or "installing FCOS with a random coreos-installer binary" use cases, since those don't have osmet.