BIND 10 Team Call 2012-11-13


  • Shane
  • Jeff
  • Jelte
  • Michal
  • Jeremy
  • Kambe
  • Jinmei
  • Larissa
  • Aharen

Sprint Progress (10 minutes)

Usual sprint check-in

Reasonably on schedule.
Jinmei: Ticket #2198 somewhat stalled.

Alpha Release Go/No?-Go (10 minutes)

Check tickets marked for alpha release

#1044 being worked on. Jelte verified that the basic operation works, but needs to make an actual tool.
Jelte: can update certificate in repository, as short-term fix

#2450, #2451 need to be done, lightweight
Jelte: probably doesn't need heavy review

Build issues?

Open files (Jinmei: not a big issue, problem in test itself, there is a workaround)

distcheck fails with perfdhcp test (on Jelte's system) library dependency fix gone in today sparc-gcc build error should be fixed in master, still catching up on box? OS X needs upgrade of Boost

Jeremy: 6 systems behind because jobs never finished, killing those manually

Decision: do release, as snapshot

Ticket for putting new certificate in repository
Jeremy: we will have to manually install it
Need to change the makefile? Yes. Okay now since we don't check it.

Beta Plans (10 minutes)

Shane will discuss

Larissa: do BIND 9/10 configuration compability things go in a beta
Shane: don't know.

Plan for beta on December 13.

Jeremy: we should try to solve multiple configurations for TSIG/data source (#1351, #2261)
Jelte: no idea when we can even start doing xfrin revision
Jinmei: we failed once, so someone else may be able to figure it out

Jinmei: beta fixing configuration syntax? (Shane: no) this is an important issue, since we will still have something that will be changed anyway, even if it is confusing it will not be the only issue

Michal: I tried to change this, but it fell apart. Maybe someone else can do it... I am afraid of that bit of code.

Jeremy: a workaround would be to rename syntax for one of them, and document that

BIND 9/10 Support Changes (10 minutes)

Engineer support cross-training (this week)
New support rota -> probably start 26 November (2012-11-26)

Resolver Plans (10 minutes)

Shane discusses

Michal: should build in DNSSEC from start
Jinmei: should have incremental versions, concentrating on performance
Jinmei: afraid after 1 year we'll have a version that performs poorly but has a lot of bugs in validation
Jelte: concerned that with stubs that even the APIs will suffer from code rot, and miss support for things we need when we validate code
Jelte: also if performs better but doesn't do expiry and stuff, that metrics don't say much

Shane: target (from Comcast) is 60k queries/second, with 80% cache hit rate and 5% DNSSEC signed zones (authoritative answers 5% are from signed zones)

Shane: can put document into Wiki so you can see the details. Discuss online and then at next team call.

about #2471 (TBD minutes)

Omitted from minutes temporarily

Out of time, sorry everyone! 2012-11-13 16:01 UTC

multi thread/process issues and logging (TBD minutes) also related to: what we should do for #2198

I'm afraid we've got lost in the use of log4cplus with multi processes and multi threads. The multi-process usage revealed the problem of mixed logs, and the recent introduction of multi threads introduced various race conditions and portability issues. To deal with these we've been developing our own hack at the lower level (not even using third party tools like the boost interprocess or thread related modules), such as inter-process file locking and in-house inter thread locks (the latter is used for other purposes, but we are going to end up introducing the try-lock primitive just for testing logging usage of the locks). We've then suffered from all lower level troubles.

IMO we're now losing major advantages of outsourcing non-critical business: avoid re-inventing wheels and concentrate on our core business, and yet having drawbacks of increasing dependency. I think we should revisit our approach based on these lessons, rather than trying to fix specific issues superficially.

Some options I can see are:

  • use our own logging module instead of log4cplus (we'll need to implement more, but we can control the things, and its availability).
  • say "use log4cplus 1.1 for advanced stuff like multi-process or multi-thread" and ask for using some workaround if it cannot be done (a strawman idea is to separate log files for each process; for multi-thread issue we may not be able to solve all problems this way but at least we can minimize the scope of the problems).

++/-- style proposal (bikeshed of the week) (TBD minutes)

I thought it was already in the style guideline but it doesn't seem to be so, so:

use the prefix style by default: i.e., int i = 0;

++i; instead of i++

it's a well known practice for non trivial types for performance reasons, but I suggest we do this for basic types like int for consistency. by being consistent, it will be easier to notice

when we use the less efficient style when it really matters.

of course, sometimes the context requires a particular style, so there can be exceptions.

if it's not obvious from the context, leave a comment about why we use the different style.

Status of trac It's down from time to time for longer periods of time. Should we have a backup plan?

Last modified 5 years ago Last modified on Nov 14, 2012, 12:13:13 PM