Let me assume that phpIPAM can actually manage DHCP and DNS server for a moment. Then you need to write two smart-proxy plugins which will be implementations of DHCP and DNS modules. The API for DHCP and DNS is simple - create, delete entry, also there are few query commands for DHCP API like list of subnets, reservations and leases and give me next free IP. Foreman talks to Smart Proxy to do these actions, when creating a new host Foreman asks the DHCP module to provide the next available IP address and performs a “lock” on it so concurrect requests take a different one.
There is no need of creating a new feature in Foreman if this is enough for you to implement stuff. Foreman core has a concept of IPAM providers in the Rails codebase and there are few implementations: DHCP (which uses what I have just described), None (manual), DB and RandomDB. They both use a database table to perform very simplistic IPAM.
Here is how it would look like:
However if phpIPAM does not perform actual creation of records, then you want probably Foreman to create those records and in that case only implement new IPAM class in Foreman Rails codebase. The interface is very simple as you can see:
An IPAM class takes Subnet model and provides
suggest_ip method which lookups an IP. Make sure to “lock” IPs so concurrent request will not have race condition issues. Unfortunately, IPAMs are not pluggable meaning that there is no plugin API to provide those from plugins. Also they are not configurable as well.
In this case, you have few options. Provide a patch into Foreman core adding new IPAM provider and use our Settings mechanism to provide configuration of URL, credentials etc. However we are trying to actually decrease amount of configuration settings long-term because we have too many.
Or you can make the IPAM pluggable and then write new Foreman plugin providing the new implementation. Then you can choose how you want to provide the configuration.