Nexus should have an API endpoint to return Oxide version

[taspelund]

The External API should have an endpoint that allows a user/operator to query what version of software is running on the Oxide system.

At the very least, this should return the major release for the whole system (e.g. r13 / r14) but it would be useful if it could also return versions of specific components like omicron (perhaps even displaying the current versions of software running on each sled/SP where appropriate).

This would make it easier to understand what code you're interacting with, especially when trying to replicate a customer environment... that way you don't need to know in advance what version they are running or what you have installed in your environment.

[iliana]

This is somewhat complex; it's ultimately part of the larger update work. We've had a lot of discussions about this but I'm not sure if it's ended up in RFDs yet, and I can't find any matching issues on the reconfigurator board, so I'll add this there. I would like to hope that operator visibility of the update system will make it into the first release that supports Nexus-driven update but I can see many reasons why it would slip to a future release.

In a Nexus-driven update world, we need to be able to report to the user a range of system versions that we're currently running at. If a rack is on v17 and the operator has requested the planner to move to v18, we're not wholly on v17 so that's not right, but there's still some sleds running v17 so just saying v18 isn't right either.

A lot of the real versions of software running on the rack are currently being plumbed into Nexus inventory (so that the planner can work), and when those are all there we can expose some or all of them to operators so they can reason about individual components on the system. Some components are still not self-describing and so it's hard to report those versions up.

In the meantime we have the internal RELEASES.adoc, which I would love to see get integrated properly into our release notes so that customers are empowered to reason about the system without having to ask us. (There's open work around SBOMs that I don't think is high priority right now; but it's not difficult for us to collect all the commit hashes as we're already doing that.) The commit hash for the console is reported in the JavaScript console in browser devtools and that can be cross-referenced against the information we otherwise would make available.

[davepacheco]

Yes, we definitely need something here. This is what we're planning to add with self-service upgrade: https://rfd.shared.oxide.computer/rfd/565#_external_api.
This tries to account for the ambiguity of "what do you show when we're in between versions"?

As for individual components and their versions: I can definitely understand wanting this for support and maybe even customers that really get into the weeds. But I think we need to be really careful with how we present it, if at all. Quoting that same section of the RFD:

We do not intend to expose update status on a per-component basis (e.g., number of sleds updated, which components have been updated, etc.). because even casually understanding this information would require a lot more information about the implementation details of the system than we expect customers to have. (For example, someone might think "12 of 16 sleds updated" means something like 75% of the work is done, but that’s not the case — not in terms of work required, nor time required, nor risk remaining.) If more details are needed on some measure of progress, it’s TBD how we’ll express that.

Part of it is trying to avoid being a call generator ("what is component X?" and "why do I have something called 'cockroach' on my system", etc.). But my bigger concern is that as a user, wouldn't this make you think it might be important for you to understand and manage these things? And wouldn't that undermine a big selling point of the product (that you don't have to understand and manage a complicated control plane)? But I could see squirreling it away in some corner for support use without making it prominent.