Skip to content

[fm] Add disk diagnoser with typed fact tables#10541

Draft
smklein wants to merge 3 commits into
mainfrom
fm-disk-diagnoser-typed
Draft

[fm] Add disk diagnoser with typed fact tables#10541
smklein wants to merge 3 commits into
mainfrom
fm-disk-diagnoser-typed

Conversation

@smklein
Copy link
Copy Markdown
Collaborator

@smklein smklein commented Jun 3, 2026

This PR provides an alternative to #10460 , using strongly-typed "enum-ish" tables for each DE's set of facts, rather than a JSON blob. It should be mutually exclusive with that PR (we either do JSON, or we don't).

The first fault management diagnosis engine: opens a case for any non-Online zpool whose backing physical disk is currently in service in the control plane, and closes it on recovery or expungement.

Supporting infrastructure introduced along the way:

  • DiagnosisEngineKind::Disk variant (Rust + DB enum)
  • fm_case_fact child table for per-engine state (one case has 0..N mmutable facts; stable UUIDs across sitreps; participates in copy-forward + GC like other sitrep child tables)
  • CaseBuilder::{add_fact, remove_fact, facts} API
  • InServiceDisk nexus-types projection consumed by FM, populated from the existing zpool_list_all_external_batched datastore method with policy filtering done in the background task

)
.execute_async(&conn)
.await?;
// Delete every child row by sitrep_id. Driving this off
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks a little involved, but it's worth noting: This is only used in tests? So doing some one-time complexity to avoid a need for future updates on each new fact type seems like a nice tradeoff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant