From listadmin at lists.bundy-dns.de Thu Apr 17 08:34:33 2014 From: listadmin at lists.bundy-dns.de (listadmin at lists.bundy-dns.de) Date: Thu, 17 Apr 2014 08:34:33 +0200 Subject: [Bundy-users] Welcome to the Bundy-DNS users mailing list Message-ID: <86d2gg31mu.fsf@strotmann.de> Welcome to the Bundy-DNS users mailing list. Bundy is a new applications framework for Internet infrastructure, such as DNS, DHCP, NTP. The Bundy framework consists of a control framework, an application interface, a statistics server, a logging framework, a remote control daemon, a configuration client tool, and numerous other tools for its development and operation. Multiple infrastructure applications modules can be run under this framework. The Bundy authoritative DNS application is one such application. Bundy-DNS is designed to be dynamically-updated, easily extensible, and to leverage a database back-end. Your Bundy-DNS listadmin! From cas at strotmann.de Thu Apr 24 13:42:05 2014 From: cas at strotmann.de (Carsten Strotmann) Date: Thu, 24 Apr 2014 13:42:05 +0200 Subject: [Bundy-users] IRC channel on freenode Message-ID: <86bnvrar8y.fsf@strotmann.de> Hi, Shane has setup a IRC channel on freenode. The channel name is #bundy-dns. For those unfamiliar with IRC, here is a link that enables joining the chat using a web-client: http://webchat.freenode.net/?channels=%23bundy-dns Join in if you have questions or need help. Be patient, the team is small and there might be times when the channel is empty. -- Carsten Strotmann Email: cas at strotmann.de Blog: strotmann.de From carsten at strotmann.de Sun Apr 27 08:43:08 2014 From: carsten at strotmann.de (Carsten Strotmann) Date: Sun, 27 Apr 2014 08:43:08 +0200 Subject: [Bundy-users] Gathering of people interested in Bundy at RIPE 68 Message-ID: <864n1fb7cz.fsf@strotmann.de> Hello, there will be a meeting of people interested in Bundy at the upcoming RIPE 68 meeting in Warsaw (https://ripe68.ripe.net). Room "Ujazdow" has been reserved for this meeting on Thursday, 15th May 2014, 18:00 - 19:00. The room is on the first floor, where the breakout room is. If you are a DNS operator, developer, or just curious about the future of the Bundy software, please join this meeting. If you cannot be in Warsaw in person, there will probably a chance of remote participation via Jabber and/or the Bundy IRC channel. Details for remote participation will be posted on this mailing list during the week of the RIPE meeting. We'll collect topics to discuss during the meeting here on the mailing list. One topic will be on how we organize the collaborative development. See you in Warsaw Carsten From tomasz at isc.org Mon Apr 28 16:26:29 2014 From: tomasz at isc.org (Tomek Mrugalski) Date: Mon, 28 Apr 2014 16:26:29 +0200 Subject: [Bundy-users] Gathering of people interested in Bundy at RIPE 68 In-Reply-To: <864n1fb7cz.fsf@strotmann.de> References: <864n1fb7cz.fsf@strotmann.de> Message-ID: <535E6515.8050701@isc.org> On 27.04.2014 08:43, Carsten Strotmann wrote: > there will be a meeting of people interested in Bundy at the upcoming > RIPE 68 meeting in Warsaw (https://ripe68.ripe.net). > > Room "Ujazdow" has been reserved for this meeting on Thursday, 15th May > 2014, 18:00 - 19:00. The room is on the first floor, where the breakout > room is. > > If you are a DNS operator, developer, or just curious about the future > of the Bundy software, please join this meeting. > > If you cannot be in Warsaw in person, there will probably a chance of > remote participation via Jabber and/or the Bundy IRC channel. Details > for remote participation will be posted on this mailing list during the > week of the RIPE meeting. > > We'll collect topics to discuss during the meeting here on the mailing > list. One topic will be on how we organize the collaborative > development. Another topic will be whether to continue DHCP development as part of Bundy. The DHCP component of BIND10 is being developed as Kea project. For now, Bundy and Kea code is almost equal, but it will diverge over time. 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. > See you in Warsaw See you there Tomek From carsten at strotmann.de Wed Apr 30 07:19:30 2014 From: carsten at strotmann.de (Carsten Strotmann) Date: Wed, 30 Apr 2014 07:19:30 +0200 Subject: [Bundy-users] Gathering of people interested in Bundy at RIPE 68 In-Reply-To: <535E6515.8050701@isc.org> References: <864n1fb7cz.fsf@strotmann.de> <535E6515.8050701@isc.org> Message-ID: <536087E2.4000304@strotmann.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Tomek, Tomek Mrugalski wrote: > Another topic will be whether to continue DHCP development as part > of Bundy. The DHCP component of BIND10 is being developed as Kea > project. For now, Bundy and Kea code is almost equal, but it will > diverge over time. > > 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 could envision (my own private view) a KEA DHCP module that communicates via a well defined API with the rest of the Bundy system. 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). - -- Carsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlNgh+IACgkQiDbv+TR5q6JXGQCfYCBqhzS/J17+K0jwRTsz6DW/ x40AmwRpxP59Kdqz8PXaKixTO4dZdld2 =TLgl -----END PGP SIGNATURE----- From tomasz at isc.org Wed Apr 30 11:14:01 2014 From: tomasz at isc.org (Tomek Mrugalski) Date: Wed, 30 Apr 2014 11:14:01 +0200 Subject: [Bundy-users] Gathering of people interested in Bundy at RIPE 68 In-Reply-To: <536087E2.4000304@strotmann.de> References: <864n1fb7cz.fsf@strotmann.de> <535E6515.8050701@isc.org> <536087E2.4000304@strotmann.de> Message-ID: <5360BED9.80601@isc.org> -----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----- From jinmei at wide.ad.jp Wed Apr 30 17:20:29 2014 From: jinmei at wide.ad.jp (=?UTF-8?B?56We5piO6YGU5ZOJ?=) Date: Wed, 30 Apr 2014 08:20:29 -0700 Subject: [Bundy-users] Gathering of people interested in Bundy at RIPE 68 In-Reply-To: <5360BED9.80601@isc.org> References: <864n1fb7cz.fsf@strotmann.de> <535E6515.8050701@isc.org> <536087E2.4000304@strotmann.de> <5360BED9.80601@isc.org> Message-ID: At Wed, 30 Apr 2014 11:14:01 +0200, Tomek Mrugalski 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. Regarding libdns++, I think the ideal way is to unify the effort, rather than maintaining the each branch of the fork. libdns++ was intended to be as standalone as possible from the beginning, and is generally less dependent on other part of BIND 10/Bundy. Maybe we should make it even more so, e.g., allowing it to be buildable separately. And, then, ideally, Kea could use it as a third party library just like Boost or log4cplus, and ISC developers could directly contribute to the Bundy version of libdns++ as they find bugs or need for enhancement. -- JINMEI, Tatuya From shane at time-travellers.org Wed Apr 30 20:54:23 2014 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 30 Apr 2014 18:54:23 +0000 Subject: [Bundy-users] Splitting out libdns++ (was Gathering of people interested in Bundy at RIPE 68) In-Reply-To: References: <864n1fb7cz.fsf@strotmann.de> <535E6515.8050701@isc.org> <536087E2.4000304@strotmann.de> <5360BED9.80601@isc.org> Message-ID: <20140430185423.731852b4@vulcan> Jinmei, On Wed, 30 Apr 2014 08:20:29 -0700 神明達哉 wrote: > At Wed, 30 Apr 2014 11:14:01 +0200, > Tomek Mrugalski 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. > > Regarding libdns++, I think the ideal way is to unify the effort, > rather than maintaining the each branch of the fork. libdns++ was > intended to be as standalone as possible from the beginning, and > is generally less dependent on other part of BIND 10/Bundy. Maybe we > should make it even more so, e.g., allowing it to be buildable > separately. And, then, ideally, Kea could use it as a third party > library just like Boost or log4cplus, and ISC developers could > directly contribute to the Bundy version of libdns++ as they find bugs > or need for enhancement. I kind of like this idea. Making anything standalone that can be standalone seems like a good idea. :) Should we go ahead and pull libdns++ out of the Bundy repository and put it somewhere on its own then? Perhaps still under the bundy-dns GitHub organization. I realize this would mean some work on both the libdns++ and rest of Bundy, but my guess is that it would not be *too* much work... Cheers, -- Shane From tomasz at isc.org Wed Apr 30 21:12:28 2014 From: tomasz at isc.org (Tomek Mrugalski) Date: Wed, 30 Apr 2014 21:12:28 +0200 Subject: [Bundy-users] Splitting out libdns++ (was Gathering of people interested in Bundy at RIPE 68) In-Reply-To: <20140430185423.731852b4@vulcan> References: <864n1fb7cz.fsf@strotmann.de> <535E6515.8050701@isc.org> <536087E2.4000304@strotmann.de> <5360BED9.80601@isc.org> <20140430185423.731852b4@vulcan> Message-ID: <53614B1C.3090800@isc.org> On 30.04.2014, 20:54, Shane Kerr wrote: >> Regarding libdns++, I think the ideal way is to unify the effort, >> rather than maintaining the each branch of the fork. libdns++ was >> intended to be as standalone as possible from the beginning, and >> is generally less dependent on other part of BIND 10/Bundy. Maybe we >> should make it even more so, e.g., allowing it to be buildable >> separately. And, then, ideally, Kea could use it as a third party >> library just like Boost or log4cplus, and ISC developers could >> directly contribute to the Bundy version of libdns++ as they find bugs >> or need for enhancement. > > I kind of like this idea. Making anything standalone that can be > standalone seems like a good idea. :) > > Should we go ahead and pull libdns++ out of the Bundy repository and > put it somewhere on its own then? Perhaps still under the bundy-dns > GitHub organization. I realize this would mean some work on both the > libdns++ and rest of Bundy, but my guess is that it would not be *too* > much work... I'm in favor of this approach as well. One particular thing that would make it also appealing for Kea is the capability to build just its C++ part, without python wrappers. We wouldn't be able to take advantage of it in the next couple months (challenging schedule as usual), but after that it seems quite attractive. The alternative - to maintain our own fork of it - is not. Tomek