libnet/cnmallocator: don't fail OnGetNetwork if unallocated

[corhere]

• Follow up to: daemon: report IPAM status for Swarm networks #50946

Summary

cnmNetworkAllocator.OnGetNetwork returned an error when the network was not in the allocator's map of allocated networks. Its own interface contract forbids that:

// The network may not have been allocated at the time of the call.
// Calling OnGetNetwork with an unallocated network should not be an
// error.

A network is in the store but unallocated in two ordinary situations:

• The allocator has yet to restore it. allocateNetworks() deliberately skips networks with no driver state or IPAM during manager init, so as not to hand out resources another network already holds.
• Its allocation failed. allocateNetwork() parks the network in unallocatedNetworks for a later retry and doNetworkAlloc() only logs Failed allocation for network %s. A VNI collision gets you here: pin a com.docker.network.driver.overlay.vxlanid_list that another network already holds and the overlay manager returns could not assign vxlan id. Allocation happens after the spec is committed to Raft, so network create has already returned success.

The consequence reached well past the one network. Cluster.GetNetworks requests every Swarm network with no filters, deliberately — the Engine API's filter semantics are richer than swarmkit's, so the matching has to happen client-side — and swarmkit runs the hook per network over that unfiltered listing. One unallocated network therefore failed the whole response. The network inspect route falls back to that listing to resolve a name and reports a failed lookup as ErrNoSuchNetwork, so:

$ docker network inspect healthy-net
Error response from daemon: network healthy-net not found

...for a network that is perfectly healthy, because an unrelated one could not report status.

Report no status instead. An absent Status is already how "no status available" is expressed — it is what a manager whose IPAM driver does not implement PoolStatuser returns — and the unallocated condition stays visible in what the allocator never filled in: an empty IPAM config and no VNI echoed back.

Scope

Only requests that ask for status reach the hook, so this affected API v1.52 and later only. Within that, the reachable paths are:

Request	Before
network inspect <name>, no scope filter	404, even for a healthy network
network inspect <unallocated>	404
network inspect <full-id> / --scope=swarm	OK — resolved from a filtered lookup that never sees the unallocated network
network ls	OK — does not request status

Testing

TestOnGetNetworkUnallocated covers the contract directly, with TestOnGetNetworkAllocated as a positive control so it cannot pass by status reporting having stopped working altogether.

Release notes (optional)

Fix `docker network inspect` failing to find a healthy Swarm network when another Swarm network could not be allocated.

A picture of a cute animal (not mandatory but encouraged)

Created with: Claude Opus 5

[vvoland]

LGTM

[thaJeztah]

Cluster.GetNetworks requests every Swarm network with no filters, deliberately — the Engine API's filter semantics are richer than swarmkit's, so the matching has to happen client-side — and swarmkit runs the hook per network over that unfiltered listing.

Haven't looked what filters would be relevant here, but is that something that could be added to swarmkit? Would it be useful / improve performance? @corhere

[corhere]

Haven't looked what filters would be relevant here, but is that something that could be added to swarmkit? Would it be useful / improve performance?

It would improve performance on a cluster with a large number of networks when the Engine API request is received on a non-leader manager as the whole unfiltered Swarmkit API response has to traverse the network. But it's still just O(n); pushing the filter into Swarmkit only shrinks n -- a linear improvement. Is the code path hot enough and the existing performance at practical limits (10k networks?) bad enough for optimizations to be worthwhile?

[thaJeztah]

Is the code path hot enough and the existing performance at practical limits (10k networks?) bad enough for optimizations to be worthwhile?

Good question; not sure; mostly considering if it's easy / not much work to add a filter, it could simplify things?