oxidecomputer / oxidecomputer/omicron

want API for looking up sleds by which slot in the rack they're in

Open
#11,089 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

api fault-management nexus
Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

#11075 updates the /system/hardware/sleds APIs to include the slot (cubby) number the sled was last seen in. It would be nice to also have a way to go in the opposite direction: given a slot number (and rack ID, because multirack), look up the sled in that slot (or indicate that no sled is present in that slot).

This probably shouldn't just return a Sled model though, because there's a third state besides "sled present and part of the cluster" and "sled not present", which is "sled physically present but not part of the cluster". We would probably want this API to also check ignition to see if there's anything in that cubby, even if there is not a record in the sled table for it. So we'd need to do some more API design here.

I think we'd probably want an API like this to hang off of /system/hardware/racks, because in a multi-rack control plane, a slot number only makes sense within a given rack. So something like:

/v1/system/hardware/racks/{rack_id}/sleds/{sled_number}

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 reviewing issue #11075 and the existing /system/hardware/sleds APIs, then examine how sled records and ignition presence are represented. Design the rack-scoped endpoint using rack_id and sled_number, covering clustered sleds, empty slots, and physically present sleds without cluster records; done means the API behavior and response states are defined and implemented.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.