[Kea-users] API/command channel for Host Reservations

[Tomek Mrugalski]

On 02.10.2015 00:22, Konstantin Orekhov wrote:
> Hello, everybody!
Hi!

> Back in April I see there was a discussion on this topic -
> https://lists.isc.org/pipermail/kea-users/2015-April/000082.html
> and I was wondering what was the outcome of this discussion? Is there
> going to be (or already is) a command channel to manipulate host
> reservations? I'd certainly love to have that as I don't really like an
> idea of allowing some other processes to write directly into KEA
> database, I'd rather have a service end-point exposed to my consumers
> instead.
We're talking about couple things here. Storing host info in MySQL is
something we had planned for 0.9.1, but due to resource (both time and
manpower) limitations didn't make it. There is one external contributor
working on this. Unfortunately, his progress is somewhat slow.

As you may be aware, we're preparing for upcoming 1.0 in the next couple
months (currently trending for early December, but the actual date may
change). I fully agree that hosts in SQL database will be a major
feature. However, we need to finish up a couple other essential features
(decline, full lease expiration w/ ddns cleanup) before we spend much
time on MySQL ourselves.

So the honest answer is that it's up to the contributor whether the code
will get into 1.0 or not. If you're interested, the work has been split
into separate tickets that are listed here:
http://kea.isc.org/wiki/HostReservationDesign
3681 is in its final stages and should be ready in couple days
3682 is implemented, but lacks unit-tests
Remaining tickets on that list are minor and very easy to do.
On a related note, you may notice that #3567 (MySQL schema) is already
done. If you download latest Kea code from git repo, you'll notice that
the database has tables for storing hosts info. Just the information is
not used yet.

As for the command to manipulate host reservations - yes, it's a fine
idea, but we haven't considered it yet, simply because we don't have
host+MySQL yet and such commands would be of limited usability without
it. Can I ask you to submit tickets for those commands in our trac
(http://kea.isc.org)? It would be great if you could describe the
business rationale for it, if you're willing to share that. If not,
simply describing what functionality you'd like to get would be ok as well.

Once the hosts storage in MySQL is supported, Kea will use it the same
way as it does for leases. There will be no caching and anything you put
into the database, using 3rd party tools, will be immediately picked up
by Kea, without any need for restarts. I understand your desire to have
a single channel and we will get it one day, but for the near future we
will have to stick with it.

> The second question - what is the more or less realistic date for host
> reservations to be moved into a DB? The reason I'm asking is the fact
> that KEA's DB backend is something that we'd replicate (with Galera for
> MySQL, for example) and have multiple instances of KEA servers using
> that replicated DB so having host reservations outside of a DB is a bit
> of a bummer for us right now.
It may or may not go into 1.0, which is currently planned for December.
This is almost entirely up to the external contributor that is working
on it. The progress is very slow. We do receive updated patches every
couple weeks, though, so he's still working on it. I understand that
this may be a disappointing answer. I'm sorry I couldn't give a better
answer at this time. Please contact me off the list if you're willing to
help with it.

> Third question - does anyone know of some web framework implementing
> RESTful API frontend for socat or, better yet, directly for KEA's
> command channel (unix sockets really, as per documentation)? Just
> curious if there's something like that already out there and I just
> couldn't find it yet.
I'm not aware of any implementations. We did talk with a group of people
who are interested in implementing a YANG/NETCONF data model that would
expose Kea configuration and statistics. This is in an early design
phase and there is no usable code yet. They plan to start actual
implementation around end of November.

Thanks a lot for your interest in Kea,
Tomek