You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a smallish refactor to the database schema for the `ereport`
table. Presently, we have `sp_type` and `sp_slot` columns, both of which
are nullable, and a `CHECK` constraint that enforces they are non-NULL
for SP ereports and NULL for host OS ereports. This was done because at
the time, I figured we could just use the sled ID column to go find the
location for host OS ereports. It turns out that this is somewhat more
fraught than I had hoped --- especially if a sled bounces or is removed
from the control plane, in which case these records don't make sense
anymore --- and it's much easier to just always record location for a
reporter when inserting the ereport. Thus, this branch changes the
schema a bit to:
1. rename the columns a bit so they're no longer SP-specific
2. make `slot_type` (nee `sp_type`) non-NULL, since even if we don't
know the sled number for a host ereport, we will always know it came
from a sled, by construction
3. change the `CHECK` constraint to allow host OS ereports to say what
slot the sled was in
4. change up some of the model and domain types to always have a slot
number
This closes#10096, which was my previous attempt to mess around with
the schema for representing ereport physical locations. Unlike that
branch, we leave the slot number nullable here
for host OS ereports, since (as discussed [here][1]) there may be
periods of time during which a sled-agent is known to the control plane,
but we don't actually know the physical location of the sled that
sled-agent corresponds to. We hope this won't happen very often, but we
must be able to represent it rather than being forced to discard any
ereports from such sleds.
There's a bit of a complex migration that attempts to backfill the
`slot` column for host OS ereports if we can find the sled UUID in the
inventory. In practice, this will not actually end up doing anything,
since...there's no code for actually collecting host OS ereports and
putting them in CRDB, so there aren't actually going to be any existing
records in need of backfilling outside of a couple integration tests.
But it felt nicer to *try* to populate this information anyway, I guess
because I'm a big dweeb or something.
[1]:
#10096 (comment)
0 commit comments