The approach used for allocating predictable IP addresses doesn't appear to account for setups where K8s nodes do not share a common subnet (e.g. L3 leaf/spine networks with per-rack subnets, BGP to the host over point-to-point links).

In those environments, the IP addresses a pod can use are dependent on where it is scheduled to run (or have to be announced in BGP as host routes, like MetalLB does for type LoadBalancer service IPs). Here, the NetworkAttachmentDefinition for the designate network would exist without a spec in K8s. This causes Multus to load the CNI config from the local node's file system on pod start and thus allows for rack or node-specific NetworkAttachmentDefinitions.

This breaks down when designate-operator tries to parse the NAD itself to obtain a range to allocate IPs from. As the NAD resource in K8s is a dummy and has no actual config in it, this fails, aborting reconciliation.

Even if we could allocate the IPs in some other fashion and put them into the config maps, this wouldn't be sufficient to make them actually work for communications.

Not sure how to fix this. Will take a deeper look and report back here. But maybe I am just mssing something?