version: Output RHEL CoreOS bootimage version

[cgwalters]

There are a lot of reasons to want to know the RHCOS bootimage version
associated with an installer - the installer pins it today, but doesn't
make the information easy to find particularly in a CI/development
environment.

This is a very small step towards something like:
#1399

[cgwalters]

Updated 🆕 with all bits addressed.

[abhinavdahiya]

The long term goal is for installer to only care about the RHCOS boot image for bootstrap node. SO i'm not sure what value we'll get from this version when we are there..?

[cgwalters]

The long term goal is for installer to only care about the RHCOS boot image for bootstrap node.

Depending on how you mean this, we are there today - that version is only used for the first boot.

(If you're thinking something like "bootstrap uses machine API for masters and pulls bootimage info from release payload" - right)

SO i'm not sure what value we'll get from this version when we are there..?

We'll always care about the bootstrap case, and this is useful for that, it's come up several times. As I note for CI cases it can be useful. And finally even in that machineapi-master future, we'll still have UPI bare metal scenarios that aren't machine API driven and this version is what people would end up using for the masters too most likely. (I mean, why inflict potentially three versions of RHCOS on them?)

[abhinavdahiya]

The long term goal is for installer to only care about the RHCOS boot image for bootstrap node.

Depending on how you mean this, we are there today - that version is only used for the first boot.

(If you're thinking something like "bootstrap uses machine API for masters and pulls bootimage info from release payload" - right)

SO i'm not sure what value we'll get from this version when we are there..?

We'll always care about the bootstrap case, and this is useful for that, it's come up several times. As I note for CI cases it can be useful. And finally even in that machineapi-master future, we'll still have UPI bare metal scenarios that aren't machine API driven and this version is what people would end up using for the masters too most likely.

But the users of UPI cannot use the OSTreeVersion right? The mirrors have boot-images based on OpenShift version like https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.1/

So how are users going to make OSTreeVersion -> OpenShift version connection?

(I mean, why inflict potentially three versions of RHCOS on them?)

What three versions?

[cgwalters]

The mirrors have boot-images based on OpenShift version like https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.1/

So...I completely understand why the filenames and versions uploaded to the mirror match the OpenShift version. But in practice, the underlying RHCOS version is...well, let's say: very useful too.

I guess we could retroactively go back into at least the buildsystem and "annotate" these "retagged" versions, but the RHCOS version is always going to show up in e.g. rpm-ostree status on the host. It will be referred to by engineering/support. And probably in the future, will show up in changelogs etc.

So how are users going to make OSTreeVersion -> OpenShift version connection?

I think the mirrors should have the meta.json generated by cosa which will contain that. I'll ask ART to do that.

What three versions?

Today we have two:

• bootimage
• oscontainer in release payload

If in the future masters are provisioned by machine API using an image from the payload, and (as seems quite possible) we're not guaranteeing that the payload-image matches the oscontainer, that makes three.

[cgwalters]

The way I'd summarize this at a high level is: We definitely want the default case for users to only have to think and care about the OpenShift version, which rolls in the OS. But the OS is such an important component with (for various reasons) its own distinct team and buildsystem, supportability just really requires it to have its own version number that's available in "details".

[cgwalters]

The other argument here is that the self version of the installer and release payload reported by version don't actually know that they're e.g. 4.1.0 either.

[cgwalters]

📞 ?

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cgwalters
To complete the pull request process, please assign smarterclayton
You can assign the PR to them by writing /assign @smarterclayton in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[crawford]

supportability just really requires it to have its own version number that's available in "details"

I disagree. What is the customer going to do with that information? Support will want to know the version of OpenShift, from which they can derive the RHCOS version. I just don't see what this buys us.

[cgwalters]

Again, the RHCOS version exists today and is accessible to tools. We absolutely rely on it during development until it gains an additional associated OpenShift version.

The degree to which the "default" customer UX is exposed to this does seem debatable to me - for example, whether the version number is available in the console.

But this openshift-install version command is already a "debug/detail" view - it has a checksum for the release image, not an OpenShift version.

[imcleod]

I do not understand the objection here. This is a genuine functional detail of the installer. It is as potentially meaningful and helpful as the installer commit, which is already emitted. Yes, this "de normalizes" something that could otherwise be looked up by foreign key, but this is not a database. The information this will provide will always be correct and may often be helpful.

[abhinavdahiya]

I do not understand the objection here.

My objections is that this information is not helpful to the users as it is not actionable.

This is a genuine functional detail of the installer. It is as potentially meaningful and helpful as the installer commit, which is already emitted. Yes, this "de normalizes" something that could otherwise be looked up by foreign key, but this is not a database.

would we load up the kubernetes version from the release image show that too? that's also foreign key on release image?

The information this will provide will always be correct and may often be helpful.

How will this information be more helpful?

[openshift-ci-robot]

@cgwalters: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/prow/e2e-openstack	d3cab5e	link	/test e2e-openstack
ci/prow/e2e-aws-scaleup-rhel7	d3cab5e	link	/test e2e-aws-scaleup-rhel7

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[cgwalters]

My objections is that this information is not helpful to the users as it is not actionable.

As Ian said: "It is as potentially meaningful and helpful as the installer commit, which is already emitted. "

This "detail" data is indeed later given a nice facade with an OpenShift version, but having an easy command to output those details saves going somewhere else to backreference. And I just don't see it as at all realistic to entirely avoid having support learn about/refer to/interact with RHCOS version numbers.

[cgwalters]

I guess one thing we could try to do is have the MCD drive the version number from the release payload down into e.g. rpm-ostree or say /etc/motd so that when you oc debug node/ it's right there in addition to the underlying version.

[DanyC97]

I do not understand the objection here.

My objections is that this information is not helpful to the users as it is not actionable.

In my opinion the info is incredible useful, especially for those folks are feeling brave enough to try and test the latest release of RHCOS/ installer

For example, let's say i want to deploy to VMware env, if i go to here i won't have a clue the RHCOS version, i'd then do s'thing like

ovftool rhcos-4.1.0-x86_64-vmware.ova
OVF version:   1.0
VirtualApp:    false
Name:          OpenShift 4
Version:       410.8.20190520.0
Vendor:        rhcos

Download Size:  16.00 GB

and then pause ... is this the version which is "bundled" with the installer from master / release branch ?

This is a genuine functional detail of the installer. It is as potentially meaningful and helpful as the installer commit, which is already emitted. Yes, this "de normalizes" something that could otherwise be looked up by foreign key, but this is not a database.

would we load up the kubernetes version from the release image show that too? that's also foreign key on release image?

The information this will provide will always be correct and may often be helpful.

How will this information be more helpful?

if you running into issues and try to reach out / open github issues etc being able to provide RHCOS version is key .. 0.02$

[crawford]

@DanyC97 I'm curious, why do you care which version of RHCOS you are using? Historically, this is a key piece of information, but in OpenShift 4 this is just another managed component in the system, so we are trying to de-emphasize it a bit (OpenShift 4 includes the OS, rather than being installed onto one).

Our objections stem from this fact. If OpenShift 4 is a collection of operators, defined by a single OpenShift release, and RHCOS is just another operand, then it doesn't make any more sense to show its version number than it would to show the console version (not to pick on console). Now I recognize that that's a great view in theory, and that the OS version may actually be needed, but I haven't seen any arguments to that effect. Every team is going to want their version numbers front and center to ease debugging, but RHCOS is the only one that is technically capable of doing so today. That's going to change in the future (the installer eventually won't know which version of RHCOS is going to be installed), so I'd rather artificially limit this information now than take it away in the future.

[cgwalters]

. If OpenShift 4 is a collection of operators, defined by a single OpenShift release, and RHCOS is just another operand, then it doesn't make any more sense to show its version number than it would to show the console version (not to pick on console).

Yes, I obviously agree with that as a starting point. But...the RHEL operating system has hundreds (thousands?) of people working on it, its own release cycle, its own security updates, its own documentation, its own ISV ecosystem, serving a lot of different use cases - and provides hundreds of millions of dollars in revenue. The console doesn't.

(And RHCOS bridges the two worlds; when RHEL releases a kernel security errata for the "8.1" stream ideally the RHCOS version communicates that, which it currently doesn't)

Another case here is ISVs who want to build kernel modules; the RHCOS version should ideally be useful for that.

And finally and most importantly for this PR - we have no plans I'm aware of to avoid the need for the "bootstrap" RHCOS version. That's what this PR is about - the bootstrap RHCOS version.

[hardys]

This is also useful for cases where you need to download the image for UPI (and also currently the metal3 IPI work, we parse the rhcos.json directly atm)

[abhinavdahiya]

This is also useful for cases where you need to download the image for UPI (and also currently the metal3 IPI work, we parse the rhcos.json directly atm)

The version is not useful to user's of UPI as the mentioned #1815 (comment)

[crawford]

And RHCOS bridges the two worlds; when RHEL releases a kernel security errata for the "8.1" stream ideally the RHCOS version communicates that, which it currently doesn't

Another case here is ISVs who want to build kernel modules; the RHCOS version should ideally be useful for that.

I see "ideally" used twice here, implying that the version number currently isn't useful for these tasks. Can we revisit this once the version number does imply this information?

And finally and most importantly for this PR - we have no plans I'm aware of to avoid the need for the "bootstrap" RHCOS version.

I can share some internal documents with you where I discuss exactly this ;)

[cgwalters]

RHCOS needs a version number that's assigned before releases (and also is immutable) - we also have checksums but those are just not comprehensible to humans. The team providing the operating system really just needs this in order to do their work usefully. Again, for exactly the same reason the command we're patching here outputs a git hash. We all agree on the high level goals.

[cgwalters]

I see "ideally" used twice here, implying that the version number currently isn't useful for these tasks. Can we revisit this once the version number does imply this information?

It is definitely useful for everyone up until a release because again we don't know what the OpenShift version will be for a given RHCOS release. I didn't just write this patch because I had 10 minutes to kill - I wrote it because it will be useful today.

[DanyC97]

@DanyC97 I'm curious, why do you care which version of RHCOS you are using? Historically, this is a key piece of information, but in OpenShift 4 this is just another managed component in the system, so we are trying to de-emphasize it a bit (OpenShift 4 includes the OS, rather than being installed onto one).

Our objections stem from this fact. If OpenShift 4 is a collection of operators, defined by a single OpenShift release, and RHCOS is just another operand, then it doesn't make any more sense to show its version number than it would to show the console version (not to pick on console). Now I recognize that that's a great view in theory, and that the OS version may actually be needed, but I haven't seen any arguments to that effect. Every team is going to want their version numbers front and center to ease debugging, but RHCOS is the only one that is technically capable of doing so today. That's going to change in the future (the installer eventually won't know which version of RHCOS is going to be installed), so I'd rather artificially limit this information now than take it away in the future.

hi @crawford, sorry for late response (busy trying to get a running cluster up ;) ). I understand the philosophy in v4 however in my opinion being able to lookup the info very quickly with little effort is key.

If i was someone working in MCO/ RHCOS group, or QA or integration or consultant i'd expect to receive/ provide this level of info rather than say go and work out yourself from the installer binary version output the RHCOS release
It could be just me but i truly dislike to not be able (or having to put a bit of effort) to provide as much info/ details to whoever needs fixing the problem and vice-versa.

[sferich888]

Do we need to have the URL to pull from be mirror.openshift.com as we comment in #1399 (comment)

[cgwalters]

xref https://bugzilla.redhat.com/show_bug.cgi?id=1731134

[openshift-ci-robot]

@cgwalters: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cgwalters]

Obsoleted by #2092