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

[RFE] Support other distributions stream metadata #644

Open
travier opened this issue Sep 30, 2021 · 6 comments
Open

[RFE] Support other distributions stream metadata #644

travier opened this issue Sep 30, 2021 · 6 comments

Comments

@travier
Copy link
Member

travier commented Sep 30, 2021

Feature Request

Desired Feature

Support an option to choose a different distribution (such as RHCOS) for download & install commands.

If this is too much work short term, we can also add a build time option to disable the download & install commands for downstream build (such as RHCOS).

The current behavior makes it confusing as coreos-installer will not download the OS the user expects it too.

@bgilbert
Copy link
Contributor

install likewise installs FCOS by default (except if there's osmet data, of course). Now that there's stream metadata for RHCOS, we'd ideally support something like --distribution rhcos --stream 4.9 in install and download.

@travier travier changed the title [RFE] Disable download command for downstream builds [RFE] Support other distributions stream metadata Oct 1, 2021
@travier
Copy link
Member Author

travier commented Oct 1, 2021

Updated for "Other distribution support" as suggested.

@bgilbert
Copy link
Contributor

bgilbert commented Oct 6, 2021

Thinking about this some more, I don't think it's practical to support RHCOS stream metadata in coreos-installer for now. Even if the user knows that they're running RHCOS 4.8, OCP policy strongly recommends that they install RHCOS using the bootimage their cluster was originally installed with. That might be a non-current 4.8 bootimage, or a 4.6 bootimage, or a 4.1 bootimage. I'm not aware of an easy way to obtain that aleph-version info from the cluster, and even if it's available, it's not clear how to act on the information.

Re build-time disablement or build-time selectable defaults, I'm not in favor of having different coreos-installer builds behave differently. That'd make it hard to safely script coreos-installer and would generally add confusion, since behavior would depend on where you happened to get your copy of the binary. In hindsight we probably should have required the target OS as a mandatory argument, but that'd be a breaking change now.

Once OCP clusters always use the latest bootimage for their respective release, this seems worth revisiting. For now, as a starting point, #649 improves reporting in download and install so it's completely clear what (OS, stream, arch, platform, format) is being downloaded/installed.

@cgwalters
Copy link
Member

OCP policy strongly recommends that they install RHCOS using the bootimage their cluster was originally installed with. That might be a non-current 4.8 bootimage, or a 4.6 bootimage, or a 4.1 bootimage. I'm not aware of an easy way to obtain that aleph-version info from the cluster, and even if it's available, it's not clear how to act on the information.

Mmm, I wouldn't say that's true anymore; we landed openshift/enhancements#679 which does include this information in the cluster.

@cgwalters
Copy link
Member

In hindsight we probably should have required the target OS as a mandatory argument, but that'd be a breaking change now.

We could do the deprecate-and-sleep approach?

@bgilbert
Copy link
Contributor

bgilbert commented Oct 6, 2021

Mmm, I wouldn't say that's true anymore; we landed openshift/enhancements#679 which does include this information in the cluster.

Ah, okay, I didn't know about the configmap. Is there a practical way for coreos-installer to use that data? (And does it work in old clusters?)

We could do the deprecate-and-sleep approach?

I'd guess that the affected subcommands are used in automated jobs that no one is looking at.

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

No branches or pull requests

3 participants