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. Re: Adding MYSQL backend support (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Feb 2016 21:25:07 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Adding MYSQL backend support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 28.01.2016 04:14, Sallee, Jake wrote:
> Thank you for your response, I wanted to wait some time before I troubled you
> by asking for an updated.
>
> May I ask how the outcome of your conversation? I am painfully curious about
> the future of this feature.
Hi,
Let me respond to this one.
The whole Kea team had a long and heated discussion about this and we
decided that storing configuration in the database is something we want
to do. It's a big and complex thing to do, so it's more like a long term
goal than a a single feature that could be implemented all at once.
On a very high level, the DHCP is about leases, host reservations,
subnets and options. In Kea 1.0 we already are able to store leases in
PostgreSQL and MySQL. The next obvious step to provide the ability to
keep more of the configuration in DB are hosts. This is something we
decided to do in upcoming Kea 1.1. When 1.1 is released, it will be
possible to store reservations in config file, MySQL or PostgreSQL.
We have not made any specific plans after 1.1, so don't hold my word for
it, but it seems likely that in 1.2 we will provide the ability to store
subnets in DBs. Options will follow up shortly.
Also, in Kea 1.1 we hope to design this solution. In particular, we want
to think and talk about management APIs. When 1.1 is released, we hope
to have a design for them more or less complete. It will cover things
like how to add, get, update or delete leases, reservations, subnets and
options. For now, we know that those commands will be JSON based and
will be sent over the command channel. One of the issues that we need to
resolve will be how to handle cases when Kea is told to add something (a
reservation or subnet) and it keeps that info in its configuration file.
Should it attempt to rewrite its configuration? Keep this updated info
in runtime and abandon it after shutdown? Provide an ability to retrieve
the whole configuration, so user could call get-config and store the
configuration somehow? It's too early to tell. But we will discuss those
issues on kea-dev when the time comes.
Keep in mind that we're not replacing config files, simply provide
another way to store the information. If your network is small and you
want to stick to config files - that's perfectly fine and that
deployment scenario will continue to be supported. On the other hand if
your network has a million devices, you likely want to keep that info in
SQL DB.
If the plan goes well, in the not so distant future the minimal
configuration would be simply a list of database credentials. I know
some guys who would be excited about that. Need more servers? Just spawn
more of them. In a sense that would be a truly stateless DHCP.
Hope that's an answer that is satisfactory for you.
Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 23, Issue 1
**************************************
