Add operator APIs for manipulating system IP Pools #9225
Conversation
bnaecker
force-pushed
the
add-system-ip-pool-apis
branch
from
4a65598 to
eed8606
Compare
| } | ||
|
|
||
| async fn ip_pool_range_list( | ||
| async fn system_ip_pool_range_list( |
There was a problem hiding this comment.
Note to self -- I think this should be a "normal", non-system endpoint. Users who can see an IP Pool should be able to list its ranges. But it does make the whole prefix / no-prefix thing more confusing.
- Add Nexus endpoints for reserving IP Pools for Oxide use or for external customer Silos - Remove check used to hide internal IP Pools, since they're all visible to an operator now - Rename operator IP Pool endpoints by prefixing `system_*`, to avoid conflicts with previous "silo-scoped" endpoints. - Handle possibility of any number of Oxide-internal IP Pools in various places where we previously assumed exactly 2 of them. - Fixes #8947 - Fixes #8226
bnaecker
force-pushed
the
add-system-ip-pool-apis
branch
from
eed8606 to
143f98a
Compare
bnaecker
requested review from
ahl,
david-crespo,
jgallagher and
rcgoodfellow
|
We should probably hold this PR until after we cut the R17 release. I'm also adding a PR to the CLI repo handling these breaking changes. |
| // select an address from. It's not clear how we do that today, but we | ||
| // could make the IpPoolReservationType more fine-grained. | ||
| // | ||
| // In the meantime, select the first one for a specific IP version, |
There was a problem hiding this comment.
An intermediate step might be to loop over internal IP pools and make allocation attempts with each pool until one succeeds.
There was a problem hiding this comment.
I might not have made this very clear, but I'm referring to something a little different here. We can definitely find an IP pool that will provide an address. I'm trying to point out that both reconfigurator and the operator need to be able to express which pools are used for different things in a more policy-oriented fashion. E.g., "I want the public API available on an address from these 2 pools" or "DNS needs to only use this one pool". That's the idea behind #8949.
There was a problem hiding this comment.
Yeah, totally understood. Was just wondering if we wanted to try all available pools in the mean time. Maybe this is a non-issue as this won't really come up based on how the RSS flow and setting up a rack currently works?
| SQL_BATCH_SIZE, | ||
| dropshot::PaginationOrder::Ascending, | ||
| ); | ||
| while let Some(p) = paginator.next() { |
There was a problem hiding this comment.
Would it be simpler and more efficient to just do a direct query without pagination here instead of iterating through pages when we just want everything in one go?
There was a problem hiding this comment.
Probably. I think we've done this in a bunch of places where latency isn't that important, or at least, less important than potentially putting pressure on the database. If it's alright with you, I'd like to keep it as-is, since it really isn't latency-sensitive. Does that sound OK?
| } | ||
|
|
||
| // List Oxide reserved IP Pools and corresponding authz objects. | ||
| async fn list_all_service_ip_pools( |
There was a problem hiding this comment.
This function is not really doing what the name/comment suggests. It's associating particular IP pools with operator specified RSS ranges.
There was a problem hiding this comment.
Fair point, I'll change it. I think it's only call-site is when doing the initial deployment after rack setup, which means the whole function should go away when we supply the pools through RSS (rather than just the ranges, which we do today).
| /// The pool is reserved for use by external customer Silos. | ||
| ExternalSilos, | ||
| /// The pool is reserved for Oxide internal use. | ||
| OxideInternal, |
There was a problem hiding this comment.
Recommend using SystemInternal for outward facing stuff to be consistent with system scoped APIs.
There was a problem hiding this comment.
Yeah, that's better. I'll rename this. It will make this PR a bit larger though. I already named it like that in the database, so I'll see if I can easily rename the variant there. That can be tricky IIRC, so it might not work.
2 participants
system_*, to avoid conflicts with previous "silo-scoped" endpoints.project_ip_pool_listandproject_ip_pool_view#8226