[kea-dev] OMAPI like feature in KEA

phirince philip phirince at gmail.com
Tue Aug 23 04:58:46 UTC 2016

On Mon, Aug 22, 2016 at 4:14 PM, Tomek Mrugalski <tomasz at isc.org> wrote:

> 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

Ah, I didn't see that. That's really useful and detailed. Thanks.

> 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.

Cool. So should I stop the development work for now? Will I be able to
contribute? This will solve a huge pain point for my company and I'm eager
to get this implemented.

How does it work?  Do you open tickets and assign it among yourself? Or
will I be able to pick up tickets which are more important to us?

> > 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.

I understand. I'm a big fan of TDD myself. I'll make sure I submit unit
tests along with code.

> 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.

I think you have already covered much more than I expected.
But the most important calls to me would be "add-reservation",
"delete-reservation" and "get-reservation". "update-reservation" would be
useful, but not absolutely required.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20160823/46ee889e/attachment.html>

More information about the kea-dev mailing list