Give end user a way to tell which IP pool is silo default #4752
Comments
Why can't we add the |
|
Because after #4261, a pool is default or not for a particular silo, so if they’re just listed across all silos, like a fleet admin listing all pools, there is no single value for is_default for a given pool. You’d have to list silos where it’s the default. Only when pools are listed in the context of a particular silo is there a well-defined single answer for is_default. |
|
Ah! Gotcha. Hmm, then I think you're right. Your first option of returning a slightly different object for the list command makes sense 🤔 Not sure I can think of a better option |
…scoped IP pools list (#4843) Fixes #4752 Fixes #4763 The main trick here is introducing `views::SiloIpPool`, which is the same as `views::IpPool` except it also has `is_default` on it. It only makes sense in the context of a particular silo because `is_default` is only defined for a (pool, silo) pair, not for a pool alone. - [x] Add `GET /v1/system/silos/{silo}/ip-pools` - [x] `/v1/ip-pools` and `/v1/ip-pools/{pool}` should return `SiloIpPool` too - [x] Tests for `/v1/system/silos/{silo}/ip-pools` - [x] We can't have both `SiloIpPool` and `IpPoolSilo`, cleaned up by changing: - `views::IpPoolSilo` -> `views::SiloIpSiloLink` - `params::IpPoolSiloLink` -> `views::IpPoolLinkSilo`
#4261 makes
is_defaulta property of the link to the silo (IpPoolSilo) and not of theIpPoolitself, which means that when/v1/ip-poolslistsIpPools for the current silo, there is no way to tell which is the default, i.e., which one instance create will pull an IP from if they don't specify a pool.The fastest way to do this would be to add
is_default: trueto the default pool in the list (if there is one). What gives me pause is that it means the endpoint no longer returns the sameIpPoolobject that we are using in all the other endpoints — this one now has anis_defaultproperty, so it would need to be a new struct. Maybe that's fine.Another (probably worse) approach would be to add another endpoint like
/v1/ip-pools/default(that path only makes sense if we don't intend to add/v1/ip-pools/{name-or-id}, and we probably do intend to for symmetry even though it's not very important). That way/v1/ip-poolswould not have to change, but we could still hit this other endpoint in the console to show which is the default. I am inclined against this because only the console would really benefit from it — a CLI or SDK consumer would have to do extra work to match what we do in the console.The text was updated successfully, but these errors were encountered: