oxidecomputer / oxidecomputer/omicron
Tracking Issue for Managing Low Disk Space Conditions
Open
Nobody has claimed this yet.
mvp
nexus
Sled Agent
storage
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Description
Spawned from RFD 312
- Tracking the right info in the DB
- Store the "maximum allowed size" of a dataset
- Add constraints where appropriate to limit this size (e.g., datasets < zpool size, regions < dataset size)
- Quotas & Reservations
- (Nexus) Determine what Quotas & Reservations should be for all known datasets
- (Nexus) Request that quotas/reservations are set in a request to the Sled Agent
- (Sled Agent) Actually apply Quotas & Reservations
- (Nexus) Request a "ballast" for reserved capacity explicitly
- Scaling
- (Sled Agent) Add metric to periodically monitor space usage
- (Nexus) Periodically query space usage of datasets, and take actions at certain thresholds...
- ... When expected, perform horizontal scaling
- ... Identify low-space conditions (long-term, we should be providing an alert to operators if we cannot remedy the situation ourselves).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading RFD 312 and the unchecked checklist in this issue. Trace the Nexus and Sled Agent areas involved in dataset quotas, reservations, metrics, and scaling, then clarify which single low-disk-space outcome is intended before defining done.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100