[Bundy-users] Gathering of people interested in Bundy at RIPE 68
Tomek Mrugalski tomasz at isc.orgWed Apr 30 11:14:01 CEST 2014
- Previous message: [Bundy-users] Gathering of people interested in Bundy at RIPE 68
- Next message: [Bundy-users] Gathering of people interested in Bundy at RIPE 68
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----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-----
- Previous message: [Bundy-users] Gathering of people interested in Bundy at RIPE 68
- Next message: [Bundy-users] Gathering of people interested in Bundy at RIPE 68
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]