coreos
[RFE] Support other distributions stream metadata
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.
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.
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, https://github.com/coreos/coreos-installer/pull/649 improves reporting in download and install so it's completely clear what (OS, stream, arch, platform, format) is being downloaded/installed.
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 https://github.com/openshift/enhancements/pull/679 which does include this information in the cluster.
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?
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.