Roll call


Welcome China back from vacation

A-team status (for R-team)

Shane: A-team's last features in review. Remaining time spent on bugfixes. Next sprint will be testing & quality checking the server. Performance delayed until Y3 because of impending refactoring.

Jeremy: Might not just be bug fixes. Also minor usability improvements.

Michal: If it annoys people enough it is a bug.

R-team status (for A-team)

Shane: Recursor works. Currently hooking up the cache to the recursive resolver.

Stephen: I'm focusing on re-doing queries with TCP if truncate is received.

Jelte: Can follow delegations and CNAMES. Can only follow delegations if glue is in the answer. Very, very short term work is getting stuff to run again. Hash table/LRU does not seem to work on some systems.

Michael: What sort of test suite do you guys have for the resolver.

Jelte: Nothing yet. No resolver behavior test.

Michael: If you guys write something that throws queries at it, write it for BIND 9 too.

Jeremy: In my tests I am doing BIND 9 also. Robert Edmunds has given me some code so I can compare responses with BIND 9 and BIND 10, using nmsg.

Shane: For recursive & authoritative.

Jeremy: Yes. I'm not doing for recursive yet, because every single query starts at the root so there will be too many differences to look at.

Jeremy: I've also started discussions with Cathy at CNNIC, they are using the TAHI test suite so we'll use that also.

Stephen: Logging work just about completed. Just have to merge to trunk. Backed out log4cxx using temporary solution just writing to console. Do need to discuss at the Prague meeting - will we use an underlying package given the problems with log4cxx or use something else.

Bikeshed 1: C++ indentation style (from bind10-dev)

Jinmei: Nothing beyond what is on the list. Difficult to describe without whiteboard or something. See e-mails for example. Just a preference matter, doing a discussion doesn't help. My suggestion is to pick one style anyway and use it consistently.

Shane: Everyone agrees that we should be consistent.

Michal: This is a holy war topic that every project has. It can be solved only by someone saying "we will use THIS and everybody obeying"

Larissa: Michal suggests a benevolent dictatorship!

Michal: Or we can vote, but everyone brings a new style!

Shane: If noone has anything beyond this, I'll make a decision and send to the list and people can argue with that.

Bikeshed 2: noncopyable redux (from bind10-dev)

Jinmei: Avoids allowing copy constructor.

Michal: Writing our own does not bring any benefit, because it is a small and thin class. Discussion is whether we want to have a another class which says "I cannot be copied" or do it directly.

Michael: Advantage of using Boost is that you can grep for it.

Michal: I don't see any reason for this, but I guess so...

Shane: Do we use boost::noncopyable anywhere? [ answer: yes ] If we do decide not to use it, should we go back and change those?

Jinmei: Yes, but it is a minor thing. In this case grepping will be helpful.

Shane: I kind of like it, but I get the impression that the team does not like it.

Michael: Why? Prefer not to depend on Boost?

Jinmei: Yes. But current implementation is quite straightforward and simple. Unlikely to cause actual problems.

Michael: I see no reason to roll our own. Can change later.

Jinmei: I have no problems with that. But I would like to add 1 more thing. In the original, Jelte's, e-mail he suggested we add it to the style guideline. I suggest we also add a general note about using Boost in our header files. So we can do this so we can discuss it beforehand so we don't overly use it accidentally.

Stephen: I would agree with Jinmei on that. We have bits we use regularly, and bits we shouldn't be using.

Jelte: And there is a big difference between headers and source.

Stephen: We have ASIO in the source code. Should we be updating that?

Michal: I think we should rely on the system having those actually, but that is a longer discussion.

Michael: Once you rely on the system having Boost install you have the option for a number of things.

Michal: We already rely on Boost header.

Jinmei: Can I ask for clarification? Does the newer version of Boost have header-only ASIO?

Michal: I guess someone mentioned it...

Jinmei: I'll check.

Michael: You're writing a DNS server and not writing ASIO libraries and such. You'd need to come up with a good reason to use it instead of writing your own.

Michal: We do use ASIO, but we bundle it instead of using the one on the system. At least we should prefer the system one instead of using the bundled one.

Michael: Boost said if you need a specific version you should lock it down in your code. That may have changed now that Boost is commonly used.

Michal: This is a longer term problem.

Michael: No reason to change if working right...

Jelte: Came because 2 in 1 review, so the style guide came up.

Jinmei: My suggestion is to grep the assignment operator, fix as many things as possible in one clean-up task. Probably not complete but fix the other things as we find it.

Shane: Okay I think that makes sense. I suggest we do use boost::noncopyable. I'll send to list, update the style guideline, and then we can have a separate discussion about guidelines for use of Boost in general.

auth and resolver ports configuration

Michal: We have 2 servers and each has a different way to configure on which port it should listen. Partly for historical reasons, but might be confusing for people. The long term goal is to configure them at runtime, so having them as a parameter for both means probably having the historical version but we can't use it indefinitely. The way the recursive server is configured is probably closer to what we want, right?

Shane: How?

Michal: First time it doesn't listen on anything, then you configure on bindctl. I suggest we could change the authoritative server to do the same, and we will fix the bug of closing old ports on the way.

Michal: I also suggest we have 2 servers and we don't know which one the user wants, but we start authoritative anyway. I propose we don't start any of them and let the user configure which one he wants. I already updated the boss to update the configuration at runtime so we don't need this step. Does anyone see problems with this? Do other people agree? If so, is this inconsistency enough to start working on it now?

Jinmei: The appropriate default behavior for listening port may be different for authoritative and recursive server. People expect authoritative server to listen to any kind of address in general, OTOH the recursive server is expected to accept queries from a limited set of addresses. If I start the authoritative server I expect it to listen on the ANY address by default, but making the interface consistent would be very reasonable and I agree with that.

Michal: You're okay changing the configuration to the manager, but that authoritative should be on port 53.

Jinmei: I don't fully appreciate the pros and cons of configuring it, but basically yes.

Michal: I see one problem with this... if there is already something listening on port 53 then the user cannot change to this configuration. You can't start the server and configure it if the component cannot start.

Shane: I think Jelte has a plan for this...

Michal: That plan is a longer-term solution.

Jelte: Not something going in the next couple of weeks.

Michal: I propose change the auth server to use the same thing the recursive server does. That is a task of 2 or 3 days. The rest of the infrastructure would be user friendly and do whatever any user might want is really a longer-term task, and I believe we need to design it better and so on.

Shane: I think it sounds reasonable. Is it going to be confusing at all?

Jeremy: A little bit, but I guess as long as we document it... I think it should be running *something*. We started the auth server, so maybe we should continue that as a default.

Michal: You have to configure the auth server anyway. You *could* start the recursive server, but I don't think it's finished so that we want to present that as the first thing the user gets.

Michael: From a PoV outside the project, I would expect it to start nothing. BIND 9 does have a default configuration... you need a file but you can use /dev/null. "named -t /dev/null" gives a default recursive-only name server. Defaults to localnets localhost

Jelte: I can see us starting the recursive server by default, but I prefer our server do nothing until I tell it to.

Michael: We may have different opinions. Maybe Larissa should ask people?

Larissa: Yeah we can do that.

Michal: I believe the authors of major Linux distributions will change the default anyway to meet their policies. If we started whatever, on Gentoo they will start nothing.

Shane: Okay lets go forward with your proposal. Make a task?

Michal: Okay.

Prague face to face meeting

Shane: Not sure a hotel will be big enough for everyone.

Stephen: How close to center of town is the CZ.NIC office?

Michal: You can take it as the center. It is not the historical center, but you can hardly park with a car...

Shane: Question... do JPRS and CNNIC want us to reserve hotels?

Likun: We can decide after we get passport and visa.

Kambe: We can reserve by ourselves.

Shane: When we get reservations we will send around. Maybe interesting for other people as well.

Shane: Focus will be on Y3 planning. If you have topics you want to discuss please let me know.

Michal: Nice to talk about the refactoring a little bit.

Michael: How we can work on BIND 9 and BIND 10 and benefit both projects. I will be there Tuesday or Wednesday.

Michal: Meta-question. Are we allowed to borrow code from different servers? Or is it a matter of pride that we don't? We have a not-finished loader of master files... there must be some already somewhere... It makes little sense to write another one! It's not that important. Anything that works might be okay I guess.

Michael: BIND 9 has meta-instructions which are not part of the master file format.

Jinmei: In some cases we already use BIND 9 code. As the general question the answer is "yes". For the master file parser, I'm not so sure. BIND 9 depends on libisc, so it will not be so easy to use the parser part...

Michal: Loader was just an example. I mean like NSD or other projects outside of ISC.

Michael: I think we'd have an internal political issue. It would also break a rule of separate code for diversity. If we can keep the code the same so we can use it both ways that would be a really big win.

Jeremy: Is this saying we're considering using C code.

Michael: If it is already written and works... a lot of projects use C code and wrap C++ around it.

Stephen: Aren't we considering writing code that goes into BIND 9 and BIND 10? [ Shane: that's the idea ] We need to write those carefully so they fit into BIND 9 and BIND 10 environments.

Shane: Michael suggested that a separate key/trust anchor manager would be something useful in BIND 9 and BIND 10.

Michael: We would consider writing it in Python. More interesting is the multi-master thing from Customer X. Every time we add a new feature you will need to do something like that. I'm trying not to put too many big things in BIND 9 if we can avoid it. We're trying to write an on-disk format that is faster to load. Sharing what we do in one project across the board is probably a net win for everyone involved.

Michal: I have one idea for the internal structure that will probably be written in C because of low-memory management.



Last modified 7 years ago Last modified on Feb 15, 2011, 4:01:29 PM