[kea-dev] OMAPI like feature in KEA

[Tomek Mrugalski]

W dniu 22.08.2016 o 07:08, phirince philip pisze:
> I've been experimenting with the KEA code to develop an API similar
> to OMAPI of ISC dhcpd. I require that feature to write a plugin for
> the foreman smart-proxy (https://github.com/theforeman/smart-proxy 
> <https://github.com/theforeman/smart-proxy>). So far, my
> experimentation has been using the hooks api of KEA. I used the
> load() entry point to register a control channel command "get-host"
> which then queries for the host reservation using HostMgr instance. I
> also want to work on a "add-host" command which will help in adding
> host reservations dynamically to the alternate source.
Seems like an awesome project!

Although so far we haven't made any explicit provisions for the hook
libs to register their own commands, what you did seems like the best
way to go.

> But before investing too much time, I just wanted to check a couple
> of things with you guys.

> 1. Is anybody already working on these features?
We're planning to. So far we made the first step, which is to write
requirements. Have you seen it?

http://kea.isc.org/wiki/ControlAPIRequirements

We hope to start internal discussion (in 2 weeks maybe?) about the scope
for Kea 1.2, which will be our next release after 1.1 goes out. We
haven't made any decisions yet, but it seems likely that we'll pick
major parts of the API and will start implementing it when 1.2 milestone
starts.

> 2. Do you think it will be a good idea to incorporate these into the 
> codebase instead of writing it as a hook?
Yes. This is somewhat trickier than it looks at the first glance,
though. Make sure you read the Contributor's Guide (kea.isc.org ->
Developer's Guide -> Contributor's Guide, or use the direct link:
http://git.kea.isc.org/~tester/kea/doxygen/d7/df4/contributorGuide.html)

In particular, we will not be able to merge a patch that comes without
unit-tests. If we receive a patch that looks good, but does not have
unit-tests, we will have to write them on our own, but that may take a
lot of time until we get around to it.

Since we have requirements for the feature you'd like to develop, make
sure your code adheres to it.

> 3. Any other feedback/suggestions/tips for me?
Sure. If you could go over the requirements document and tell which of
those calls are important, which are nice to have and which not
interesting for you would be a great feedback. If you have any other
comments or proposals for calls that we have missed, I'd love to hear
about that, too.

In the early September we will likely start working on the design. I
don't expect any revolutions, just a description what the actual
parameters should be, with some explanation how the code should work
under the hood etc. The discussion will go on kea-dev, so feel free to
weigh in.

> Thanks in advance, -PP
Thanks for using Kea and writing code for it!

Tomek