The message ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET misleadingly includes the text "shared network"
kea-dhcp4 failed to allocate and address to a client (this failure itself is not part of this bug report) but logged very confusingly:
2022-04-25 19:15:05.943 WARN [kea-dhcp4.alloc-engine/29305.140568371398528] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 ], cid=[], tid=0x7ff4f761: failed to allocate an IPv4 address in the subnet , subnet-id 103, shared network
This is doubly confusing - firstly, the subnet in question is not part of a shared network (and in any case, no shared network id was given in the logged message) and secondly, the Kea Messages Manual says that this message is emitted specifically when the subnet is not part of a shared network anyway. (This was also confirmed from code inspection by engineering). Please can you amend this message and get rid of the 'shared network' text.
Here's the relevant text from the Kea Messages Manual:
ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET
%1: failed to allocate an IPv4 address in the subnet %2, subnet-id %3, shared network %4
This warning message is issued when the allocation engine fails to allocate a lease for a
client connected to a subnet that does not belong to a shared network. The first argument
includes the client identification information. The second and third arguments identify
the subnet. The fourth argument specifies the shared network, if the subnet belongs to a
shared network. There are many reasons for failing lease allocations. One of them may be
the address pools exhaustion or existing reservations for the free leases. However, in some
cases, the allocation engine may fail to find a suitable pool for the client when the pools
are only available to certain client classes, but the requesting client does not belong to
them. Further log messages provide more information to distinguish between these different
cases.
As well as fixing the logging, the explanation in the documentation also needs to be updated - it is particularly bizarre to start the explanation saying that this logging is for a client connected to a subnet that doesn't belong to a shared network, and then to go on to explain that the fourth argument is used to identify the shared network to which the subnet belongs. Um... ??