bundy

* Modular * Extensible * Friendly *

[Bundy-users] Gathering of people interested in Bundy at RIPE 68

Tomek Mrugalski tomasz at isc.org
Wed Apr 30 11:14:01 CEST 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30.04.2014 07:19, Carsten Strotmann wrote:
>> If the collaborative decision made will be to continue
>> developing DHCP in Bundy, there will be tons of patches flying
>> back and forth between Kea and Bundy. Having them done in orderly
>> manner would require some planning.
> 
> this is a good point. No decisions have been made.
I think that regardless of the decision, some patches will be shared.
Even if the decision would be to not develop DHCP in Bundy, Kea is
using libdns, libutil and many other libs. There will be fixes in
those libs done in both repos.

> I could envision (my own private view) a KEA DHCP module that 
> communicates via a well defined API with the rest of the Bundy
> system.
That's certainly doable, but not trivial. We have received strong
suggestions from various people that BIND10 framework is too big for a
DHCP server. Therefore the major objective of upcoming Kea 0.9 is to
eliminate BIND10 framework and make Kea a stand-alone server (i.e. to
start it from command-line, read config file and don't require Python3
at all). This is quite radical change compared to what we were using,
but that will make Kea much lighter and easier to deploy.

Having said that, our config file is/will be in JSON format. In fact,
it's exactly the same format as we used to receive from cfgmgr over
msgq. We're going to retain commands processing, but they will be
unusable for a while (until we decide how to organize commands
delivery and processing).

> This would reduce the inter-dependencies between the projects, but
> still allow KEA to be operated as part of a larger Bundy system,
> with the synergy benefits (DHCP and DNS integration etc).
That's something I'd love to see. The major challenge here would be
integration and testing. On a related note, it would be quite nice
feature if Bundy framework could allow running any arbitrary daemon.
The integration could as simple as writing a .spec file.

Anyway, that's definitely a worthy topic for discussion in Warsaw.

Tomek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTYL7ZAAoJEB99lszqrhlNgzQH/iYICI5FSy0xR89elx2NK/52
v1rj9DlHIQj7yg/8xXzw3V74YYN0lGehgTMoDo9V2yMcLRFlvbBDuf0Gj/9Hf0WU
xB1sLldsoi5SLRC/AZwqL5nZox5Scd/8etpcwNtPSQMxl4qtrHQtxki9QthVgsG2
VbX0oLiOW2nUqB5LYlqNn7LMbcFQSHulHuKf6R2j3S5gSKG+ct2Ybh3do3ttwOwA
HNAulnO6xfJuQhRoq0YbcsMEsaFMSgLGd3gDGao9JXozLbYLTW3gnyE7aigyYR0k
+DMog5YhOzrf9K+HWI/9S64+qLZN+LKNplPqsU9dFR5VndqHkU/OIb9/lPSpWpk=
=BibW
-----END PGP SIGNATURE-----