Reorder blueprint read to the end of loading #9603
Conversation
| // - Successful reads are validated inside the reader loop (must match | ||
| // the original blueprint exactly, or the assert_eq! fails) | ||
| // - "Not found" errors are expected after deletion | ||
| // - No other errors should occur |
There was a problem hiding this comment.
I'm mildly (but pleasantly) surprised the "no other errors should occur" condition passes. I could imagine a case where we load from two tables then do some operation to match up rows, and bail out if we don't find a match. I think we do do that for pending MGS updates, but we're matching up against the effectively-immutable hw_baseboard_id table in that case, which doesn't get torn by blueprint deletes.
Would it be a problem if we got other kinds of errors? I suspect the error message would imply the blueprint was invalid in some way, which is technically true if it's a torn read but not very useful to the caller.
There was a problem hiding this comment.
I've been thinking about this - I think that we can roughly summarize the task of loading a blueprint as:
- Read database rows (within the blueprint)
- Read database row (top-level blueprint). Done last to avoid "tearing".
- Parse blueprint from database rows, validate if it's correct (e.g., the "row-matching" logic you describe)
I dunno if we can do this in practice, but I'd really like to do those steps in that order. I think it's possible that we're doing some of the "parsing" work before we read the final top-level row.
If we can identify "the data from the database is invalid, skip all parsing", that would basically split the world into a "possibly-deleted" and "known-not-deleted" partitions - and we could do all the parsing after we determined that the rows don't belong to a deleted blueprint.
Not sure this PR is doing this perfectly, but the TL;DR of my push is:
- Move database reads earlier
- Move blueprint parsing later
Partial fix of #9594