Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. OMAPI like feature in KEA (phirince philip)
2. Re: OMAPI like feature in KEA (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Aug 2016 10:38:06 +0530
From: phirince philip <[email protected]>
To: [email protected]
Subject: [kea-dev] OMAPI like feature in KEA
Message-ID:
<caggyfeklmbbbrna3j9abahhslij0q0y_9wfbjtkb3b7tnjy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Team,
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). 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.
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?
2. Do you think it will be a good idea to incorporate these into the
codebase instead of writing it as a hook?
3. Any other feedback/suggestions/tips for me?
Thanks in advance,
-PP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20160822/3891d839/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 22 Aug 2016 12:44:24 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] OMAPI like feature in KEA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 29, Issue 6
**************************************
