Closed bitcollector1 closed 1 year ago
Hey, I'll have a look into implementing these for dhcp4 first and then look at the other daemons.
It might take some time to get the test infrastructure built, all the useful commands implemented first and then the tests but shouldn't be too long, let me know if there are any api specific commands that you'll use other than the generic shared network/subnet/lease etc... commands!
Thanks again for all the work towards this wrapper, it's working great for me so far. I'm still learning how it all works TBH
One thing we are starting to leverage is the host reservations, these are proving to be super helpful and we will most likely redesign our current workflows and tooling around this awesome capability!
No problem! It's great to see someone other than myself using it
I've got the first iteration of dhcp4 commands for the config backend working which includes the common api calls, including finally getting the reservation api calls working as they don't work with a memfile which is what I've mainly been testing with recently.
I haven't extensively tested it yet, but have some basic tests implemented which they all seem to pass so I would suggest heavily testing it manually in case there are some weird stuff that goes on with the cb_cmd hook, I will release it as a pre-release on 0.6.0a0, try and test all the commands I've implemented so far for dhcp6 then release it as 0.6.0
Daemon/Area
dhcp4
Feature/Enhancement you are proposing
We use a configuration database, so need to use the remote commands
https://kea.readthedocs.io/en/kea-2.2.0/api.html#commands-cb-cmds
Reason for Feature/Enhancement
Note: It is recommended that libsubnet_cmds.so not be used to manage subnets when the configuration backend is used as a source of information about the subnets. libsubnet_cmds.so modifies the local subnets configuration in the server's memory, not in the database. Use libcb_cmds.so to manage the subnets information in the database instead.