Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't default to FCOS #1225

Open
runcom opened this issue Jun 28, 2023 · 9 comments
Open

Don't default to FCOS #1225

runcom opened this issue Jun 28, 2023 · 9 comments

Comments

@runcom
Copy link
Member

runcom commented Jun 28, 2023

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
Copy link
Contributor

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
Copy link
Member

cgwalters commented Jun 28, 2023

I think basically:

  • Change all of the docs to specify --distro right now
  • Change the code here to emit a warning + sleep(10) if --distro is not specified unless we're running on FCOS

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
Copy link
Contributor

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
Copy link
Member

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 coreos/stream-metadata-rust#3

@bgilbert
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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):

  • We're running from a Live environment with osmet
  • --image-url or --image-file are specified

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

@bgilbert
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants