oxidecomputer / oxidecomputer/omicron

[fm] want provenance for rendezvous-created objects to include the sitrep version

Open
#10,913 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Debugging fault-management non-important non-blocker
Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

Presently, when FM rendezvous creates an object (i.e. a support bundle or an alert) it is tagged with the IDs of the sitreps in which it was requested and created. These are intended for traceability when debugging (although in some cases I believe the presence of any non-null sitrep ID is used to indicate that something came from FM at all). It has occurred to me that it would be useful if these also had the version number of the sitreps in which they were requested and in which they were created. The version number can serve as a rough "about how long ago was this thing requested/created?" while debugging.

We could, potentially, turn the IDs back into version numbers by JOINing with the fm_sitrep_history table, and just do that in omdb when actually displaying a rendezvous object. However, we may not always be able to recover a version number from an ID, if if (as I intend to in #10904) we start deleting old sitreps from the history table. Therefore, it might be better if this was denormalized onto the records for the rendezvous-created objects, so that it could outlive the sitrep. I dunno.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing FM rendezvous creation for support bundles and alerts, then inspect the fm_sitrep_history table and the existing sitrep ID fields on those records. Decide whether requested and created sitrep version numbers should be denormalized, and consider behavior when old sitreps are deleted. Done means rendezvous-created objects retain both version values for debugging.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.