wiki:WeeklyMinutes20130501

BIND 10 Team Call 2013-05-01 @14:30 UTC

Attendees

  • Shane
  • Jeff
  • Mukund
  • Aharen
  • Jinmei
  • Kambe
  • Jeremy
  • Paul
  • Fujiwarams

Sprint Status

Okay, we just started, but we have a standard placeholder here. :)

http://bind10.isc.org/query?group=status&milestone=Sprint-20130514

Jeff noticed Mukund using Greenhopper on Jira. Functionality now gone - trying to sort out error. Anyone who wants to play with this in the next couple of days will not find it working.

Mukund: Missed one ticket, #2809, another 6 points added.

Shane: should we remove some tickets?

Mukund thinks we are okay.

Jinmei: progress is not bad, the rest not so difficult except #1622

Jinmei: #2775/#2776 can be closed?

Mukund: Michal wants someone to review the text

Release Roadmap

Jeremy would like to have a real BIND 10 roadmap. This makes complete sense. Probably the next reasonable things are:

  • May release (waiting for #2903, maybe tomorrow)
  • Shared-memory release (early August)
  • XFRng release (early December)
  • Hooks release (hard to estimate - what's the design?)

Jeremy away 16th/17th and 21st-24th May.

Other things:

  • Hopefully logging fixes get put into the shared-memory release.
  • RRL can also go into the shared-memory release. (Depends on progress on shared memory task for next couple of sprints, we can also consider adding at some later point.)
  • MySQL support will go into the XFRng release, or possibly an interim release beforehand.

Jinmei: Update about MySQL status

In face to face meeting reported intermediate results - quite difficult to use indexes for iterating over zones. Performance penalty for AXFR out. After some experiments found a way to use indexes in that scenario, but also some (probably) fundamental limitations for that. Size of the columns must be up to ~760 bytes (names, RDATA, whatever). In practice this should be okay for most cases, but in principle may cause problems.

Shane: so we need to index on RDATA, or does this matter at all?

Jinmei: issue about sorting output (discussed in face to face meeting); if we are okay with unsorted results there are several ways; if we want sorting then in MySQL we need indexes for all covered data

Mukund: why would we need sorted results?

Jinmei: for XFR out we do not necessarily have to do that. it may look weird.

Shane: and some buggy software may have problems, since BIND 9 does sort

Jinmei: if we use this to load into memory, this may also affect performance

Jinmei: even quite large RRSIG will still fit in this implementation, so in practice it should be okay, except for unusually large RR, but this is in generaly probably an acceptible limitation Depends on type of database, but InnoDB is only realistic choice

Shane: Also we need to consider MariaDB at some point.

XFR Behavior Configuration

I don't know if we need a discussion, but it came up on the mailing list. https://lists.isc.org/pipermail/bind10-dev/2013-April/004590.html Ticket about this in the current sprint, #2911 Do we want to provide backward compatbility in configuration:

  • In general
  • In this specific case

Resolution may require configuration change/update, and deprecating a database configuration option (or updated in incompatible way). In general we can provide compability, but in general it makes the implementation more complicated. Up to some point it is probably better to keep it simpler, but for users it is more inconvenient.

Shane: we could have a way to deprecate features

Jeremy: if we change syntax, the old stuff is just ignored... may take a long time to notice...

Shane: maybe we should check for configuration items not understood?

Jeremy: can depend on which modules are running or config plugins that are loaded

Shane: but within a module we have the .spec file...

  • AP: Shane to make a ticket for warning on unrecognized configuration stuff
  • AP: Shane to put issue about deprecating stuff smoothly into the IdeasDump? page

Jinmei: what about this specific case?

Shane: I'd like to say we can just make the change...

Jinmei: always possible someone will get upset...

Mukund: at least document conspicously in release notes

Jeremy: as long as we have the ticket about warning on unknown, it is probably okay

Shane: if we branch 1.1 beta 2 before #2911 gets merged then I am fine with that. :)

A.O.B.

  • resolver data

Shane still trying to get upload system to work as he expects. :-/

  • Next week's meeting?

Planning on NO CALL next week. Shane away. Will continue shared memory work next sprint planning.

Bug fix, and should improve server response from a few percent to maybe up to 50% (depending on response type) Overhead for synchronous code that is not needed - quite substantial; still used for asynchronous version Can re-run benchmarks after merge. :)

Last modified 5 years ago Last modified on May 6, 2013, 5:00:38 PM