[nexus] add cases to FM sitreps #9492
Conversation
hawkw
added
the
fault-management
|
This failure installing rustc components in the |
|
|
||
| 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.
There was a problem hiding this comment.
Thinking about this some more, yeah, I think I'd rather leave this as-is. I was wondering if there was a way to just ON CONFLICT DO UPDATE the sitrep ID for these when inserting a new sitrep, but that would make them potentially disappear if a new sitrep is inserted but never made current. I think I'm going to leave this as is and just allow them to be copied a bunch and deleted by sitrep GC normally.
| .map_err(|e| public_error_from_diesel(e, ErrorHandler::Server)) | ||
| } | ||
|
|
||
| fn fm_sitrep_read_ereports_query( |
There was a problem hiding this comment.
I know it took a ton of thought and effort (and db restructuring) to get here, but this ended up looking very simple - nicely done.
There was a problem hiding this comment.
Thanks! Your advice was very helpful here. :)
|
CI failure for |
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.