Plugins » Infoblox

Could you confirm that hosts in the ip address range in question are reachable (no firewall interference) via tcp pings (port 7) and/or icmp pings? Reachability via pings is required for correct operation of free_ip functionality.

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.

There was no discussion about this: the functionality was always present in the isc_dhcp provider and is now reused in other providers.

I would have thought that to be because there was a lack of a better alternative for that provider.

We cannot rely on built-in "free address" functionality (which is what was used before) as it fails in cases when more than one request for an ip address is made in parallel/rapid succession -- it always returns the same address which breaks provisioning workflows.

I don't see how thats worse/different from the 'new' approach which can and will fail under certain, not uncommon, circumstances (as outlined in previous posts) as well.

In cases where address pools mix addresses managed by Foreman with addresses managed manually or via other systems, there is no other way for Foreman to determine address availability other than by using icmp/tcp pings, which is the reason we rely on them.

Well, you cant rely on icmp/tcp pings either, can you? It's proven by this issue! The information about address availability is in InfoBlox, so the natural thing I think would be to just ask InfoBlox to do the work for you (as it worked pre 1.17) or at the very least provide this as an option and let the user decide which method to use.

Ideally, Foreman should have an address pool solely dedicated to it.

Thats an unreasonable requirement to make in many larger environments.

As it is for us, I haven't even set up from/to ip addresses in my subnets in Foreman. I dont have to, since that stuff is already configured in InfoBlox. With this change all that has to be configured twice - once in InfoBlox when setting up a subnet there, and then once again in Foreman. If any changes are made in InfoBlox, they have to be made in Foreman as well. And InfoBlox admins and Foreman admins are often not the same team, so I see a lot of risk for misaligned configuration between the two.

An option if you want to maintain some internal logic in Foreman getting final decision which ip to use might be to just ask InfoBlox for all ip addresses in the subnet:

/ipv4address?network=10.0.0.0/24

This returns all ip addresses in the subnet with information about reserved ranges, ip status (used/unused), mac address and so forth. So you could pick an unused ip from that output (which would essentially replace the random selection being made today) and then reserve it internally in Foreman so it doesn't get picked again. That would both prevent errors when creating multiple hosts simultaneously as well as prevent that Foreman suggests 'bad'/unusable ip addresses.

I understand the theory about problems 'when more than one request for an ip address is made in parallel/rapid succession', but are there any actual bug reports regarding this? I would be interested in reading those.

Please see "related issues" for the history of the issue being discussed. Additional discussion can be found in PRs associated with the tickets.

Hi everyone, in the last days i researched a LOT about this, since we also use Infoblox with Foreman. It took me some time to understand how it works currently, but i hope i have the right understanding now to propose some ideas.

Our situation is somewhat special (is it?), since we do not define DHCP Ranges in Infoblox and also define any IP which has any record on it (in Infoblox speak: "USED") as used. We only want "UNUSED" IPs to be used for provisioning. This clashes with the way the plugin works right now: It looks either for all "Host"s or for all "Fixedaddress"es (depending on the setting) and picks IPs not used by those. But we have some IPs which only have a DNS A record for example and currently those IPs could be used. We recognizes the problem pretty fast, because when the DNS record shall be created by the Foreman provisioning, we get an error that the IP already has a DNS record.

I want to change the plugin to switch (configurable via a setting!) to the "/ipv4address" endpoint of the Infoblox API in the "all_hosts" methods. It needs some tweaks, since the returned data is slightly different to what "/record:host" or "/fixedaddress" return ("mac_address" instead of "mac", "ip_address" insead of "ipv4addr"). Also the returned mac_address is empty for IPs only having a DNS A record (in that case i try to set a dummy mac like "00:00:00:00:00:00"). I am currently working on transforming that stuff, so "build_reservation" does not need to be changed (since it is used in other places as well) and still can create DHCP reservation objects. The unused IP search then does not select IPs, which have (still for example) a DNS A record, because those then look like a used reservation.
This addresses Adams proposal.

I think that logic is better than resolving a DNS name to see if the IP is used, as Sébastien proposed.

Also, like Sébastien i don't like pinging IPs to see if they are free - in our case this is useless anyway, since we have pretty strict firewall rules. But as Lukas already mentioned this is now configurable, so everybody can decide on its own if one wants that or not (however i am in the opinion to have that disabled per default and not enabled per default, like it is now).

We already agreed here, that the Infoblox method to find free IPs should not be used, as it always returns the same free IP.

Adam, there can be reasons that someone wants a different from/to range in a subnet to be used by Foreman than the range the subnet itself offers. For example it could be that only a part of it shall be filled by hosts to keep enough IPs free as additional IPs for a host - i had a real world case at my previous job.

And Lukas, i tried to implement Infoblox in the external_ipam stuff, but i stopped it, because external_ipam lacks to work with mac adresses completely. In our environment we need the DHCP records the current plugin creates to have the systems booting and provisioning correctly. This is not possible in external_ipam, since already the code in the foreman core does not provide the mac addresses. So right now external_ipam can only be used to only manage IP usages in the IPAM systems - the DHCP stuff would need to be addressed with DHCP ranges or similar. This does not fit to our use case. Of course the core could also be refactored to provide this, but i thought it would be smarter to improve this plugin - even despite the fact, that the used "infoblox" gem source code is already marked as archived.

Tell me what you think about my idea (changing the plugin) - i am working on it anyway and will raise a PR anyway, since we need it.