[bind10-dev] Sprint Planning Meetings on 30 Nov/1 Dec

[JINMEI Tatuya / 神明達哉]

At Wed, 01 Dec 2010 23:49:31 +0900,
JINMEI Tatuya <jinmei at isc.org> wrote:

> > Planning
> 
> Based on the above thought, my gut feeling is:
> 
> > 1. Schedule for the next release cycle
> > 2. High-Level aims for the next release cycle
> 
> The mid size story is "be able to load textual zone file(s) into
> memory, and be able to respond to queries to these zones" (no DNSSEC
> support, no zone transfer, no dynamic update, no reload).  This may be
> too conservative, and perhaps we can do a bit more.

In yesterday's call, Stephen asked me to send more broken-down details
of my proposal.  As is often the case with what's asked in conference
calls, I'm not sure if this is exactly what I was asked, but I'm
sending my idea anyway.

> And (examples of) small stories would be:
>  - load a normalized zone file into memory and simply return an
>    authoritative answer (no NXDOMAIN or NXRRSET, delegation, no
>    additional section)
(and no authoritative section (like BIND 9's "minimal-responses"), no
wildcard, no CNAME/DNAME handling)

This is a way too incomplete server, but I chose it as the target for
the next sprint because
- I think (perhaps optimistically) we can complete it within two
  weeks.  Here, "complete" means merging to trunk after review.
- For a minor leaf domain, this is actually quite sufficient
  functionality, that is, if an "example.com" server can return the
  correct AAAA or A RRset for "www.example.com", that should cover the
  vast majority of the need required for the server (if "example.com"
  is a very minor domain).  It would still not be for "production
  use", but at least we can demonstrate how it works for one practical
  scenario.

There may be other sub stories that meet the same high level
background, but assuming we use this as our goal for the next sprint,
I've broken down this story into small development tasks.  Each task
is intended to be completed within a day or so, and is expected to be
reviewed and merged right after that.  It's based on some optimistic
assumptions though: the tasks may still be too big; especially if so,
review may take more time and require more review-revise cycles.  If
our consensus on some task is too big, we should divide it.  Also, if
it turns out some task takes much longer than the agreed estimation,
we should use the lesson for the next sprint.

Common notes about tasks:
- below, newly introduced class/method names are tentative.  we
  may find better names as we actually consider design details and
  implement them.  Likewise, although the task description includes how
  to implement it, it's a hint so that the task can be as clear as
  possible, not a requirement.  If the developer finds a better way to
  achieve the goal, it should be preferred.
- All implementation tasks are assumed to be developed test driven.  So
  "tests" are naturally included in the task.
- About documentation: I've noticed that often "ready for review"
  patches contain insufficient or almost no documentation.  So I
  included a "documentation task" for each implementation, so that we
  can include the task load for it from the planning phase (like
  tests, hopefully we'll eventually consider documentation as part of
  the implementation task from the beginning, then we can unify these
  two tasks).  For this reason, it should be done by the developer who
  works on the corresponding implementation task, and code review
  cannot be called unless both the implementation and documentation
  tasks are done.
- About python binding: ideally we should add python binding for all
  new data source stuff at the same time when the corresponding C++
  library is written (although it may be separate tasks).  But for
  this sprint I'd skip it, because this may be a tentative interface,
  and we are not sure if we can complete the listed tasks (without
  python bindings) within a single sprint.

Tasks:
1. complete outstanding review and merge: #415
2. complete outstanding review and merge: #418
3. complete the necessary stuff of RBT.
  We only need add and find operations for our initial sprint.
  Complete the implementation (+ documentation) for this part, review
  and merge.
4. update to the ZoneTable class
  so that it internally uses the RBT.
5. documentation on the update to ZoneTable
6. review and merge of task #4
7. implement MemoryDataSrc class.
  The MemoryDataSrc contains a ZoneTable object, which consists of
  (pointers to) MemoryZone (see below) objects.

  For now, we don't make it a derived class of AbstractDataSrc because
  the interface is so different (we'll eventually consider this as
  part of the generalization work).

  This class has two methods:
  - addZone(): takes a (shared)pointer to MemoryZone and stores it to
    the ZoneTable
  - findZone(): takes a domain name and returns the best matching
    MemoryZone in the form of ConstZonePtr
  These two should be mostly trivial and I personally think it can be
  done in a single task.
8. MemoryDataSrc class documentation.
9. review and merge of task #7.
10. A simple (master) zone file parser.
  It parses a "normalized" zone file, where "normalized" mean:
  - no directives ($xxx, @, etc)
  - TTLs are numbers
  - no multiline RR
  - no comments
  - no omission (owner name for RRs of the same owner name, TTL, RR Class)
  - RRs of a single RRset are not interleaved with RRs of a different
    RRset.  That is, the following sequence shouldn't happen:
    examle.com. 3600 IN A 192.0.2.1
    examle.com. 3600 IN AAAA 2001:db8::1
    examle.com. 3600 IN A 192.0.2.2
  - no mixed ordering of RR parameters; only accept the form of
    <owner name> <TTL> <RR class> <RR type> <Rdata (single line)>
  (note: BIND 9's named-compilezone (from text to text) can convert an
  arbitrary zone file in the "normalized" form:
  % named-compilezone -f text -F text -o example.com.norm example.com example.com.zone)

  This can be a simple free function (not a class), which takes a path
  to the zone file, the origin name, and RR class, and a callback
  functor.  It calls the functor for every RRset built from the zone
  file.  Some level of validation against origin/RR class should
  better be performed, but if it takes time it can be skipped at this
  time.  In either case it should be documented.
11. zone file parser documentation.
12. review and merge of task #10.
13. Introduce the MemoryZone class.
  MemoryZone is a derived class of AbstractZone (see #418) dedicated
  for the in memory data source.  We begin with renaming the Zone
  class currently implemented in #418 to MemoryZone, and move it to a
  separate .h/.cc files.  (AbstractZone to "zone.h", and MemoryZone to
  a part of "memory_datasrc.h".

  It internally contains an RBT, whose data entry is a (pointer to)
  some kind of list of RRsets.

  Major methods for MemoryZone are relatively complicated, so I'd
  separate the task for them (below).
14. MemoryZone class documentation.
15. review and merge of task #14.
16. MemoryZone::load() implementation
  This method takes a path to a zone file, and calls the zone file
  parser function.  In its callback, it adds the owner name of the
  RRset to the RBT, and adds the given RRset to the list (which is the
  data of the RBT node for the owner name).  There may be some corner
  cases, such as duplicate RR types.  For now we can ignore them, but
  it should be documented and addressed properly later.
17. MemoryZone::load() documentation
18. review and merge of task #16.
19. MemoryZone::find() implementation
  This method takes a domain name and RR type, and searches the RBT
  for the given name.  If found, it searches the associated list, and
  if it finds an RRset of the given RR type, return it.  For now, we
  only consider an exact match.  Partial match (delegation case) can
  (should) be ignored and treated as 'not found'.
20. MemoryZone::find() documentation
21. review and merge of task #19.
22. configuration knob
  We should be able to specify tuples of "zone origin, RR class, path
  to zone file" by updating auth.spec.pre.in, and
  AuthSrv::updateConfig().  In updateConfig(), we'd create a new
  MemoryDataSrc (if not exist yet) and a new MemoryZone for the
  specified zone, load the zone file to the MemoryZone, and add the
  zone to MemoryDataSrc.
23. configuration knob documentation
24. review and merge of task #22.
25. implement normal query processing
  This is an update to #418.  It should take MemoryDataSrc (instead of
  a zone table).  Also, if zone->find() is successful, add the
  returned RRset to the answer section of the response.  As part of
  this task, we'd also update AuthSrvImpl::processNormalQuery() so
  that if a memory data source is configured call the separate
  Query::process() method instead of DataSRc::doQuery().
26. update document of query processing
27. review and merge of task #25.
- (optional) performance measurement
  The resulting performance at this point is not so important (and
  even if it's not good yet we shouldn't jump into optimization now),
  but if we (someone) have time measuring it may be interesting.

---
JINMEI, Tatuya