-
Notifications
You must be signed in to change notification settings - Fork 54
Initial schema updates disallowing default IP Pool for the internal silo #8964
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
bnaecker
commented
Aug 30, 2025
- Add database constraints that ensure that we can't set a default pool for the Oxide internal silo. Add tests for this specifically.
- This is part of Enforce relationship between IP Pools reserved for Oxide services silo #8948, but does not resolve it.
ce147e2
to
afb56f3
Compare
- Add database constraints that ensure that we can't set a default pool for the Oxide internal silo. Add tests for this specifically. - This is part of #8948, but does not resolve it.
afb56f3
to
9f49f97
Compare
This is a small step towards #8945. To date, we've assumed that our internal silo has exactly 1 IP Pool. That's special, created at rack initialization, linked to the silo, and not operator-modifiable. We can't do that in the long run. For one thing, we need IPv6 IP Pools, but we also want to allow operators to delegate pretty much any IP Pool to the internal silo. That will eventually be used to determine which networks our services need addresses on. The first step, implemented here, is just disallowing a default IP Pool for the internal silo, enforced as a check constraint in the database. |
Keep endpoint non-idempotent, and catch check violations explicitly
I’m not finished with the updates from your feedback yet. I’ll re-request review when it is ready.
|