oxidecomputer / oxidecomputer/omicron
IP pool quotas and utilization
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Description
Discussed with @zephraph this morning about the controls we have around IP pools. I don't think these are high priority, but wanted to get these notes down.
As an operator it would be useful to see and control the utilization of the IP pools within a rack. IP pools can be assigned to zero or more silos and a silo can have zero or more ip pools.
Currently we do not provide visibility in to how utilized those resources (IP addresses) are. Both at a silo and fleet level view it would be useful to see the used and remaining number of ip addresses per pool. (Though we may want to be more restrictive about what the silo can see). Further in the future it would be even better to see that data broken by their usage type (external ip, floating ip, nat, ?).
Once we can see this data, it would also be very helpful to be able to control the use of an IP pool. Where currently we can divide up a block of IPs into multiple pools of fixed sizes and apply them to individual silos, it can be time consuming to manually manage them. In the case that I have a single large pool of IPs and would like to allocate a fixed number to a given silo it would be helpful to be able to set a quota on the (silo, pool) pair and track it with the other quotas we place on silos.
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
No files, tests, or entry points are named. Start by locating the IP pool, silo, and quota APIs, then clarify the intended visibility and quota behavior; done requires an agreed scope for utilization reporting and per-silo pool quotas.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, backend, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100