[kea-dev] kea-dev Digest, Vol 22, Issue 7

Tomek Mrugalski tomasz at isc.org
Thu Jan 28 15:12:00 UTC 2016


On 28.01.2016 13:22, Ray Hunter (v6ops) wrote:
>> We would like to get going with the implementation, so please send your
>> comments no later than 2016-01-26 (the next Wednesday).
> 
> I missed the feedback deadline but FWIW I think creating too complex a
> classification syntax risks leading you into the maintenance rathole
> that you were trying to avoid when writing KEA: you are in danger of
> recreating a high level language (in the configuration).
Ack. That's a fair point. We talked about this internally and we think
that while is may have some of the drawbacks of the old implementation,
we are confident that we'll be able to avoid most of them.

One of the major annoyances of the old code is that there's a lot of
interconnected pieces of code that is hard to debug, test and rewrite if
necessary. Our new implementation is written in C++ with each token
(representing an option, a field, an operator etc) is separated into its
own class. Each class has its own unit-tests that checks its proper
operation. Those tests are run on a daily basis on many (around 20)
different systems. This gives us a high confidence that, while there may
be bugs, it should be working well in most cases.

As with most other features in Kea, this one is also well documented.
If the whole Kea team joins first SpaceX expedition to Mars tomorrow,
whoever takes over would have reasonable chance to understand the code
and continue its development.

The configuration language of the old ISC DHCP has many issues, but many
people like it a lot and depend on it heavily. Kea does different things
differently and people seem to be willing to try something new, but in
some cases the barrier of learning a bit of C++ is a problem. It will
get easier when the number of examples available will get bigger.

> I humbly suggest that your time might be more productively spent on
> providing a set of (tested) libraries and example hooks that would allow
> others to quickly develop specific hooks directly in c++ that can be
> loaded into the DHCP server. Packet and options parsing, packet and
> options construction for outbound packets, config parsing, and database
> lookups to file/mysql etc., are all reasonably painful operations and
> could benefit for a standard and well-documented API.
This is the long term plan. We will get there eventually, but this road
has its own problems. The major problem here is testing. With the number
of example libraries we provide, the number of test cases grows
exponentially (for N libraries you have at least 2^N combinations, or
even more if you want to load them in different order).  And that's just
assuming that each hook library doesn't have any configuration knobs.

There's another aspect here. Kea is a new software than still needs to
earn its reputation. Saying that upcoming Kea 1.1 will have improved
client classification and reservations storage in PostgreSQL and MySQL
sounds better than "hey, we've added a bunch of extra hook examples".
At least we think it does. :)

I'm secretly hoping that in the not so distant future there will be
people who will be writing their own hooks and would be willing to share
their code. But I get your point - we, the Kea developers, have to help
to bootstrap the process. I'll see what I can do about that.

Thanks a lot for sharing your thoughts on this one.
Tomek



More information about the kea-dev mailing list