Need API endpoint for listing IP Pools scoped to a project

[bnaecker]

Need a way to list the IP pools available to resources within a project. That means any IP Pool not reserved to another project, or reserved for a specific project.

[smklein]

Related: #2055

I thought there were not "IP Pools scoped to a project", but rather, "IP Pools which are available to a project". I think that's a subtle distinction, but also a matter of ownership.

[bnaecker]

Yeah, I was rushing here. I meant that the endpoint should be project-scoped, and that should return the IP Pools available to a project.

So ../projects/{project_name}/ip-pools returns all IP Pools that can be used by Project project_name.

[bnaecker]

I'm catching back up to a bunch of work I was only vaguely aware of in the last few months. This issue is possibly still relevant, but much simpler after #2056. There is no project ID at all on IP Pools anymore, so this just needs to return all non-internal pools. That logic may change in the future as we flesh out the scoping of pools, but for now, it's just anything that any developer can use. I.e., all projects will return the same list now.

[lifning]

just to clarify -- for the time being, this would literally be a duplicate of /v1/system/ip-pools's current behavior (which already does .filter(dsl::internal.eq(false))), with the purpose being that /v1/projects/{}/ip-pools would be subject to potentially change in the future?

[rmustacc]

Yes, I believe that this is correct. Let me try to provide some surrounding context here.

One of the main things that we know that we're going to need, both from prior experience and from customer feedback, is that they want a way to have a group of IPs that can be used for provisioning that is eventually restricted to a subset of users, whether that ACL is eventually associated with a project, a silo, or some other more complex thing (but critically not based on user id). So the idea is that really if you're using the CLI or any other thing, the question of what images, IP pools, or other resources can I use is ultimately specific to the project and therefore by using a project-scoped URL you'll get what you can use.

So today the only ACL that really exists is the internal-only bit. I think we want to look at what it means to update all the user and terraform tooling to use this endpoint. The fact that the system IP pools interface filters out internal things raises a question for me because it makes me ask how does an operator change that.

Hopefully this helps a bit. Thanks for picking this one up @lifning.

[zephraph]

Sounds good.

I think the shape of the API is likely going to need to be different though.

/v1/projects/{project}/ip-pools only fits with our API if all you can do is list a resource. If you need to be able to get a specific resource from the collection or access sub resources (like ip pool ranges) then you'll want to use /v1/ip-pools with project being a query selector. I'm happy to chat with you about what that should look like.