BSS currently reads the url parameter to know what host is making the request because Weave/MetalLB was historically obfuscating the request IP/MAC in the packet.
In SI, we don't expect the packets to be obfuscated.
In ISC DHCP, there was a config macro for embedding the host mac in the configuration that made it trivial to create a BSS request in a DHCP config that included the MAC as a query parameter.
Neither kea, nor dnsmasq supports that macro which has meant that our configuration files get really long and errors are riskier.
For SI, we are not using Weave/MetalLB and returning to a HTTP Request based method for assessing which node is making the request is possible. We should allow the code to follow this path and remove complexity from the BSS clients.
BSS currently reads the url parameter to know what host is making the request because Weave/MetalLB was historically obfuscating the request IP/MAC in the packet.
In SI, we don't expect the packets to be obfuscated. In ISC DHCP, there was a config macro for embedding the host mac in the configuration that made it trivial to create a BSS request in a DHCP config that included the MAC as a query parameter. Neither kea, nor dnsmasq supports that macro which has meant that our configuration files get really long and errors are riskier.
For SI, we are not using Weave/MetalLB and returning to a HTTP Request based method for assessing which node is making the request is possible. We should allow the code to follow this path and remove complexity from the BSS clients.