[nexus] add cases to FM sitreps #9492
Conversation
hawkw
added
the
fault-management
|
This failure installing rustc components in the |
| // TODO(eliza): we should populate cases and assert they get | ||
| // cleaned up... |
There was a problem hiding this comment.
Since we're adding deletion operations in this PR -- WDYT about addressing this comment before we merge?
|
|
||
| comment TEXT NOT NULL, | ||
|
|
||
| PRIMARY KEY (sitrep_id, id) |
There was a problem hiding this comment.
Interesting; I would have figured the id would be the PK, but I'm not opposed to it being (sitrep_id, id) either.
There was a problem hiding this comment.
the ID can't be the PK on its own since we would like to be able to insert a new sitrep non-transactionally without having removed the previous one, and we need to know the sitrep ID so that we can delete the records associated with it when GCing old/orphaned sitreps.
There was a problem hiding this comment.
actually, hmm, perhaps there is a way to have these records not contain the current sitrep ID, and GC them separately? that might make this table a lot smaller. i'd have to think about it.
| map.entry(case_id).or_default().insert_unique( | ||
| fm::case::CaseEreport { |
There was a problem hiding this comment.
Woah this is weird formatting
Cases, as described in RFD 603, give diagnosis engines a mechanism to group together ereports (and eventually, other fault management data) as part of a sitrep. This branch adds database tables for representing cases, and for associating ereports with cases. Subsequent branches will add a mechanism for sitreps to request alerts, which will also be associated with cases.
This branch was factored out from #9346, where I've been prototyping a diagnosis engine implementation. Although aspects of how the DEs themselves will work are still in flux, I think that cases, along with other parts of the database machinery such as the impending alert-requests branch, are pretty much nailed down.