Problem:
IPAM DHCP Infoblox started to give random addresses from configured subnet ranges after upgrade to 1.17.
Addresses could be free or already used which leads to failed host creation.
Expected outcome:
suggest new should give free addresses.
Foreman and Proxy versions:
Version 1.17 for Foreman and Proxy
Are you seeing an actual issue, or commenting on randomness of addresses being returned? If it is the latter, then this is by design. Additionally, before an address is considered available icmp and tcp ping checks are used to verify its availability. All addresses known by smart-proxy are considered unavailable.
I’m seeing an actual issue. Host creation through either the form or the api fails with address already used error randomly.
I’ll create an issue relative to this problem.
Issues #23523 and #23534 have been created.
One for the generic logic, and one for the infoblox plugin.
As I’m writing in the issue, I understand why the logic has been changed but it makes some assumptions that are not misleading.
An IP not pingable is not always a free IP. Server could be down or, foreman host may not be able to reach the serveur (think about a host using a proxy to reach the foreman url for example).
I responded in the tickets you created, but will also respond here for posterity.
We cannot rely on vendor implementations for locating available ip addresses, none (we used MS dhcp and infoblox implementations in the past) work in workflows where multiple hosts are created in quick succession/parallel. Current implementation of “free ip” functionality used in smart-proxy relies on hosts being able to respond to tcp/icmp pings. This is done so address pools can be simultaneously managed by both foreman and 3rd-party dhcp servers.
There’s a request to make ping checks optional, but this will only work (when implemented) with address pools managed solely by Foreman.
I responded in the ticket but do it now for completeness.
This is a bug since it broke valid production setup for no good reason.
Even with dedicated address pools to foreman, we end up with address already assigned by foreman without any warning.
Host creation may succeed or not. Dhcp creation is after the cloning, so we may wait quit a long time before having an error on the dhcp creation.
I added a few hints to improve the solution, but not involving the provider in the IP selection will lead to a problem to be dealt with sooner or later.
Please take into consideration there may be a problem in your solution as users report regressions.
Even with dedicated address pools to foreman, we end up with address already assigned by foreman without any warning.
This shouldn’t be happening. Please file a bug report.
I added a few hints to improve the solution, but not involving the provider in the IP selection will lead to a problem to be dealt with sooner or later.
You are suggesting using dns PTR queries to determine ip address availability: this will not work in all setups, and isn’t as reliable as icmp/tcp pings (stale/outdated zone records is an issue). Some backends may provide a way to check if an address is available, I don’t know if infoblox API has something of the sort.
Indeed, it does not work in all setup. It’s just a quick fix to make the production running again in our setup
My point is there is no silver bullet for checking if ip is available or not.
icmp ping, tcp connection, ptr check, IPAM provider query, it all depends on the setup one has a put in its environment.
So, let’s make a parameter in the dhcp.yml to configure the correct option.
