[kea-dev] 'Key collaborators'

[Tomek Mrugalski]

On 24.10.2015 16:42, Simon Westlake wrote:
> Just found Kea from a Google search - I've used ISC DHCPD extensively in
> the past. I saw the post on the site saying you were looking for some
> 'key collaborators' to test the API, and I may be able to provide
> exactly that with a new project I'm working on.
Hi Simon!

Yes, we're always looking for new collaborators. In particular, we're
interested in people who are integrating Kea with various external
systems. I'm very interested in hearing more about the project you're
working on. If you're not comfortable with sharing the details on this
public list, feel free to contact me privately.

Anyway, here are some things that may get you started. There are several
APIs that Kea provides. The most frequently used one is Hooks API, which
provides an ability to extend the server behaviour at all processing
stages. This API is described here:
http://git.kea.isc.org/~tester/kea/doxygen/ (See Hooks API for
DHCPv4/DHCPv6 for a complete list). Many of those hooks are already
being used in actual deployments. But it's always nice to get feedback
on them. There's an upcoming change expected in 1.0 that will change the
API slightly (skip flag replaced with enum status). There are several
new hooks planned for 1.0: lease{4,6}_expire, lease{4,6}_decline and
lease{4,6}_recover. Some of them are already implemented, while others
are still in progress. If you're interested, it would be great if you
could use them and see if they do what you want and provide general
feedback (any parameters missing, whether they're working as expected etc.).

Another thing that may be interesting to consider is to write a hook
library. Over time, we hope to accumulate a set of libraries, somewhat
similar to apache modules. If this is something appealing, we can
definitely discuss it. It may be a tricky task, though. So definitely
please tell me what your plans are and I will offer suggestions and
maybe a bit of help. I honestly admit that the whole Kea team is
scrambling for 1.0 release by end of the year. We're already overbooked,
so the help we can provide in the next couple months is limited at best.

Another API that's definitely could use some love is our control channel
API. It currently offers around 10 commands with most of them focused on
statistics, like get statistic, reset statistic, reset all, get all etc.
If your project is about building a system around Kea, you'll definitely
want to look at that API. The idea here is that the API uses JSON syntax
to communicate, so the communicating entity could be written in any
language, e.g. python or perl. Currently the only channel we have is
Unix socket, but the approach is generic. It's possible to implement
other communication modes (tcp, https, etc.). Implementing new commands
is certainly a viable option. Tell us what's interesting or useful for
you and we'll discuss it further.

Speaking of statistics, this is a new feature and it hasn't been tested
extensively. If you're looking for testing type of work, that's
certainly an interesting area.

Yet another thing that you may be interested in is our database API. We
do have generic API (C++ class) and concrete implementations for memfile
(custom C++ database), MySQL and Postgres. The backends are able to
store lease information, but not host reservations. There's one
contributor who works on adding MySQL storage for hosts. As far as I can
tell, nobody is looking at Postgres at this time. We did receive one
patch for Postgres, but the contributor disappeared when I asked for
unit-tests :( Implementing host storage for Postgres would definitely be
a major feature, if that seems interesting for you.

Speaking of the databases, we do have a maintenance script called
kea-admin. It does its job, but it's rather basic. If you're looking for
sysadmin style contributions, this may be of interest to you.

We did receive inquiries about commands that would provide unified
interface for lease (add/get/update/extend/remove) and host
reservations. This is something we'd love to have, but due to scheduling
constraints we can't do on our own. Yes, you can extract that info from
the database directly, but it would be great to have an the same
interface, regardless of what the actual storage is.

If you consider donating code, keep in mind that we do have high
standards regarding the code we accept that may be surprising and
disappointing at first: every method must be documented, there must be
unit-tests, the code must build on all platforms we support, user
documentation must be provided etc. We can't accept any code that is not
maintainable in the long term. People sometimes send us patches with the
"it works for me!" attitude. That is nice, but often not sufficient. We
expect the Kea project to be at least as long lasting as the current ISC
DHCP (which is old enough to buy alcohol). We also need to ensure that
the code will work on other platforms. There's an extensive description
of the process in Kea Contributor's Guide:
http://git.kea.isc.org/~tester/kea/doxygen/index.html

Looking forward to hear more from you,

Tomek Mrugalski
Kea lead developer