The Reconfigurator ops guide describes how to figure out what's going on when an update is stuck:
https://github.com/oxidecomputer/omicron/blob/main/docs/reconfigurator-ops-guide.adoc#debug-stuck
but it does involve a few different commands to query a few different components. It'd be handy to have a command like omdb reconfigurator update-activity (that's a terrible name) that reports a bunch of it together. It could report:
- whether an update is in progress
- similar output as
update-status: counts of components at various versions
- the last blueprint (or the last few), what time they were, and what they did (i.e., their comment and/or a diff)
- (a warning if the last blueprint was too long ago and the update is not finished)
- any errors or warnings from relevant tasks: blueprint planner, blueprint execution, rendezvous, etc.
- the latest planning report from some Nexus
- the latest execution report from some Nexus
It's worth spending some time figuring out how to best present this information so that it's as clear as possible what the current status is.
The Reconfigurator ops guide describes how to figure out what's going on when an update is stuck:
https://github.com/oxidecomputer/omicron/blob/main/docs/reconfigurator-ops-guide.adoc#debug-stuck
but it does involve a few different commands to query a few different components. It'd be handy to have a command like
omdb reconfigurator update-activity(that's a terrible name) that reports a bunch of it together. It could report:update-status: counts of components at various versionsIt's worth spending some time figuring out how to best present this information so that it's as clear as possible what the current status is.