oxidecomputer / oxidecomputer/omicron
Feature Request: Identify "missing/moving disks" in FM
Open
@mergeconflict is already working on this.
Since Jul 9, 2026.
fault-management
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Description
This issue tracks the FM system identifying the following condition: "You have a disk, which you expected to be a part of the control plane, but it is not alive anymore".
This issue also aims to (eventually?) distinguish between "disk missing" and "disk present in slot, powered off".
This issues does not intend to cover other cases where a present disk is otherwise unhealthy.
We're going to need to complete a couple sub-objectives to finish this work:
- We must be able to identify an "intended configuration" for system hardware. This can probably be inferred from the current set of control plane disks?
- We'll need to rule out false-positive signals - e.g. , "Sled not present", which could happen during reboot
- We'll need to access additional libtopo information to infer: "is a disk present in a slot". Additionally, we'll need to add information about disks to inventory, regarding "what is their identity" and "where are the disks currently attached".
- We may want a layer of post-processing via CRDB tables on the Nexus inventory system, identifying edge-triggered changed between inventory collections for a particular disk. This CRDB table could identify: "for a given disk (vendor, serial, model), where has it been physically attached to the system (by sled + slot)"? This history information could help us identify when a disk has moved.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.