Plugins » Infoblox

Maybe one could supersede the find_free_ip with an infoblox specialized version to avoid this problem.

We stopped using vendor implementations across the board, as they break workflows where multiple hosts are being created quickly/in parallel. Could you confirm that tcp and/or icmp pings work on the subnet in question -- this is required for this functionality to work.

1- That's a huge regression. It used to work in 1.16, it's no longer the case.
2- Some of the subnets are not reachable by the foreman host.
3- I understand quite well the case you're trying to fix, however, the validation with tcp or icmp, is, IMHO, very unreliable.
For example, if the host is powered off, then its IP address is considered as available which is not correct.
In our case, creation of the DHCP entries creates its entries in the infoblox DNS, a good test would be : get the reverse lookup from the IP.

The smart_proxy is doing something like this :
take any random address in the range
check if it available (first tcp_connect on the 7 port, or ping the machine).
Sends back the selected adress if it's available.

The host gets the available IP from the smart proxy, tries to create a dhcp entry with the given address, then fails miserably because the address is already taken.

IMHO, the function to check should be selectable : ping, tcp (port configurable), dns, dhcp (check leases or static provisionning) or provider specific.

Hm, relying on icmp to decide if an ip address is available for use or not seems like a bad idea to me. If a host is down, it wont work. If an ip address is reserved for future use, it wont work. If icmp is not allowed from the dhcp proxy to the subnet, it wont work. I just see a lot of cases where this would fail, which seriously disrupts automation pipelines. Any link to the discussion where this decision was made? I don't see anything in the release notes, and this seems like a pretty big change that would affect a lot of customers.

We use InfoBlox which has worked very smoothly in this aspect, by Foreman using infoblox api methods to get next available ip address. This change really puts me off updating to 1.17.

As stated by Sébastien, an option to choose to use provider specific method to allocate ip address would be welcome.

I like the idea of checking availibility of an IP address to be extendable function provided by individual implementations. We slightly touched this in #27692 but it is probably worth revisiting this.