Expected output would be a locations: [ "member-name" ] value for the eth10 network. Because it only exists on exactly one cluster member and not on the others.

I suspect we will need to do something different so you can see the different IPs on each cluster member for yje same interface name.

I suspect we will need to do something different so you can see the different IPs on each cluster member for yje same interface name.

I don't see IPs on the network list. See screen below

OK thanks, looking at the implementation I can see its only returning the configured IPs from the DB, not from the interface itself.

So it may be OK to just populate the locations field for unmanaged networks and if we ever want to return IP info for those, then we'll have to also add support for per-member target param, as IPs would be per-member info.

I also note that this logic from /1.0/networks/<network> is missing from /1.0/networks:

When running sudo ip link add eth10 type dummy on one of the cluster members, the new dummy eth10 interface only shows up in the GET 1.0/networks response, if the API request is sent to the member that the interface was created on. When sending the API request to another cluster member, the interface does not show up.

So we might need a GET 1.0/networks?target=:member filter to get the list of one specific cluster member. Or plan B is to have GET 1.0/networks collect the list of networks from all cluster members.

After contemplating on this issue and reading a bit of lxd source, I think adding a target filter to the GET 1.0/networks endpoint is the easiest way to resolve this. See the linked PR #14419 above, implementing it.

The other proposed solution, to populate the target field for non-managed networks, is way more expensive. Because the cluster member handling the API request would have to reach out to all other members. This seems costly, complex and more error-prone (thinking of split brain or partially down cluster members). With the added target filter, we don't need to populate the location field as far as the LXD-UI is concerned and can resolve this issue with the simpler solution.

After contemplating on this issue and reading a bit of lxd source, I think adding a target filter to the GET 1.0/networks endpoint is the easiest way to resolve this. See the linked PR #14419 above, implementing it.

The other proposed solution, to populate the target field for non-managed networks, is way more expensive. Because the cluster member handling the API request would have to reach out to all other members. This seems costly, complex and more error-prone (thinking of split brain or partially down cluster members). With the added target filter, we don't need to populate the location field as far as the LXD-UI is concerned and can resolve this issue with the simpler solution.

I agree that it's more complex and costly to reach out to other cluster members to populate non-managed networks but I think it's necessary in this case for consistency in API responses. For example, if I have a LXD cluster and a remote configured in lxc for it. I would expect to see all networks in the cluster on a call to GET /1.0/networks. This is the same as in storage volumes/buckets where there is no target parameter on GET /1.0/storage-pools/{pool}/volumes/{type}/{name}.

Just to expand on this a bit. My main contention is that although the UI will know to call GET /1.0/networks?target={name} for all cluster members, I wouldn't expect a CLI user to call lxc network list --target {name} against all cluster members to get the full picture of all networks in the cluster.

Agree

I also agree with the more involved correction of the network api long term. I think we discussed the target filter as well before, which #14419 introduces. Can we merge that right away? It unblocks the UI work by providing a way to fetch the list of available interfaces per member.