wiki:ProjectPlan

Introduction

This page explains the deliverables and dependencies for BIND 10. The idea is that this contains the information in the Roadmap section of the Trac site, but in a more human-friendly format.

What we have here:

  • A list of the components, with some guesses about how much work is required for each bit of them.
  • A list of non-software components we need to build to actually make the system.
  • Some dependencies between the components (although only at the large scale).
  • A possible timeline to get us started working.

Notes about this preliminary Y1 plan:

  • This includes a bit of time for survey of existing technologies, and for research, but not that much. Some of this work needs to occur, probably outside of the scope of deliverables.
  • Review & sign-off is not documented as a separate step. Each line-item is assumed to be worked on by one engineer, but with review by a separate engineer.
  • There is no integration time listed here.

Authoritative-Only Server Software Components

These are the components we need to build BIND 10 as an authoritative-only server.

A01. (InterModuleCommunication) Inter-module communication (low-volume, Unix, non-embedded)

This is the communication framework that different components will use to signal infrequent events. So, for example, this may be used to alert any interested components that the server is now answering for a new zone. This is not intended for high-bandwidth processing, such as logging or statistics.

We'll try to re-use existing technology, hence the "survey of existing technologies".

Depends on: none
Time estimate: 4w

  • Requirements documentation (3d)
  • Survey of existing technologies (1w)
  • Developer documentation (2d)
  • Tests (1w)
  • Examples (2d)
  • Benchmarks (3d)

A02. Configuration

This is the work necessary to store and manipulate configuration for the various modules. Anything that goes in named.conf is the kind of thing we are talking about. This will need to be much more dynamic, so it will probably look a lot like an event system.

We'll try to re-use existing technology, hence the "survey of existing technologies".

Depends on: none
Time estimate: 5w

  • Requirements documentation (3d)
  • Survey of existing technologies (1w)
  • Developer documentation (3d)
  • Examples (4d)
  • Tests (1w)
  • Administrator documentation (1w)

A03. Logging

BIND 9 has a sexy logging system now, and we need to do at least as good in BIND 10. The idea is to create a system that provides the functionality of the BIND 9 logging, but is also easy to extend.

We'll try to re-use existing technology, hence the "survey of existing technologies". "Existing technology" may be BIND 9.

Depends on: A01, A02

  • Generic Logging Module
    Time estimate: 6w
    • Requirements documentation (including performance) (3d)
    • Survey of existing technologies (1w)
    • Design & developer documentation (3d)
    • Code (5d)
    • Examples (2d)
    • Tests (5d)
    • Benchmarks (3d)
    • Administrator documentation (3d)
  • Syslog logging
    Time estimate: 2w
    • Requirements documentation (2d)
    • Design & developer documentation (2d)
    • Code (2d)
    • Tests (2d)
    • Administrator documentation (2d)
  • File logging
    Time estimate: 3w
    • Requirements documentation (3d)
    • Design & developer documentation (3d)
    • Code (4d)
    • Tests (4d)
    • Administrator documentation (2d)

A04. Statistics

This is the bit that we use for both gathering and publishing statistical information of all kinds. BIND 9 has historically been weak here, although it has come a long way with 9.5 and 9.6 (thanks Michael!).

We two APIs for components here. One for gathering statistics, one for publishing them. We also need an actual publisher, like what we have now for BIND 9.

Depends on: A02, A03

  • Statistics gathering API
    Time estimate: 4w
    • Requirements documentation (including performance) (3d)
    • Design (3d)
    • API documentation (2d)
    • Code (1w)
    • Tests (1w)
    • Benchmarks (3d)
    • Examples (3d)
  • Statistics publishing API
    Time estimate: 4w
    • Requirements documentation (including performance) (3d)
    • Design (3d)
    • API documentation (2d)
    • Code (1w)
    • Tests (1w)
    • Benchmarks (3d)
    • Examples (3d)
  • HTTP/XML statistics publisher (like BIND 9, also serves as an example)
    Time estimate: 3w
    • Design (2d)
    • Code (1w)
    • Tests (1w)
    • Administrator documentation (3d)

A05. BigTool program

This is the command-line interface into BIND 10. Roughly, this is a command-line tool that does everything:

http://bind10.isc.org/wiki/CommandLineTool

We want it to work dynamically, querying the other components to find out what commands are possible. This insures that the tool is always in sync with the other components, and also that 3rd party components can work with it.

Depends on: A01, A02

  • Initial version
    Time estimate: 10w
    • Requirements documentation (1w)
    • Design (2d)
    • Developer documentation (1w)
    • Code (2w)
    • Tests (2w)
    • Examples (1w)
    • Administrator and user documentation (2w)
  • Second version
    Time estimate: 4w
    • Design of new features (1w)
    • Code (1w)
    • Tests (1w)
    • Verification of extensibility (including developer documentation) (2d)
    • Update of administrator and user documentation (1w)

A06. !DNSPacket API

This is the low, low-level component needed to crack and uncrack DNS packets. This will have to be written in C++ for performance.

Depends on: none
Time estimate: 8w

  • Requirements documentation (including performance) (1w)
  • Initial API
    • Developer documentation (3d)
    • Code & abstract classes (1w)
    • Concrete classes (1w)
    • Examples (2d)
    • Tests (1w)
    • Benchmarks (1w)
  • API review
    • Updated documentation (2d)
    • Code modifications (3d)
    • Updated examples (1d)
    • Test modifications (3d)
    • Benchmark review (2d)

A14. First Server (MILESTONE 1)

This is the first runable milestone - a stand-alone server that does not do much, but incorporates all of the earlier pieces.

Depends on: A01, A02, A03, A04, A05, A06
Time estimate: 2w

  • Design (2d)
  • Developer documentation (2d)
  • Development (4d)
  • User documentation (2d)

A07. DataSrc API

This is the API that we use to access and manipulate the database that authoritative DNS zones are stored. It is a basic CRUD (Create Read Update Delete) database, with a lot of work to make it more efficient for DNS.

Depends on: A01, A02, A03, A04, A05 (maybe)
Time estimate: 9w

  • Requirements documentation (including performance) (1w)
  • Initial API
    Time estimate: 4w
    • Developer documentation (3d)
    • Code & abstract classes (1w)
    • Examples (2d)
    • Tests (1w)
    • Benchmarks (1w)
  • In-memory implementation (rbt?)
    Time estimate: 5w
    • Design & developer documentation (1w)
    • Code & concrete classes (2w)
    • Examples (?)
    • Tests (2w)
    • Administrator documentation (2d)

A08. TSIG

Basic TSIG support. Nothing too tricky here, except for the crypto requirements (although since this is hashing, we may be able to do this in a flexible way).

Depends on: none
Time estimate: 5w

  • Requirements documentation (including performance) (2d)
  • Crypto support review (1w)
  • Design & developer documentation (2d)
  • Code (1w)
  • Examples (2d)
  • Tests (1w)
  • Benchmarks (3d)

A09. ACL

We need ACLs in many parts of the system (when a packet is received, when we do a lookup for a packet, when someone connects to the control channel, and so on). I think sticking with IP networks and TSIG keys as the identifiers are okay for now, although we may want to make this more abstract. This will likely have to be written in C++ for efficiency, eventually.

Depends on: A02, A08
Time estimate: 6w

  • Requirements documentation (including performance) (3d)
  • API design, implementation design, developer documentation (4d)
  • Code (1w)
  • Examples (2d)
  • Tests (1w)
  • Benchmarks (1w)
  • Administrator documentation (3d)

A10. AXFR/IXFR/Notify processing

This is the logic that handles zone transfers, both in and out. It's not too complicated (hopefully). We may try to build this with simple threaded (or process) logic. Ultimately this may need to be more sophisticated, but hopefully the OS will break on TCP sessions before it breaks on threads/processes.

Depends on: A01, A02, A03, A04, A05 (maybe), A06, A07, A08, A09
Time estimate: 5w

  • Requirements documentation (including performance?) (3d)
  • Module/class/schema design (3d)
  • Developer documentation (2d)
  • Code (1w)
  • Tests (1w)
  • Benchmarks (memory-only? or not at all?) (2d)
  • Administrator documentation (3d)

A12. Monitoring

This is monitoring of the system. It is a bit vague right now, but we clearly need the ability to watch what is going on.

Depends on: A01, A02, A03, A04, A08, A09
Time estimate: 4w

  • Requirements documentation (including performance) (1w)
  • Developer documentation (3d)
  • Code & abstract classes (2d)
  • Concrete classes (3d)
  • Tests (5d)
  • Benchmarks (2d)

A11. SmallMammal (formerly !AuthDNSQuery) module

This is the Y1 deliverable - the thing that ties the other components together into something that can actually answer queries. The logic here can be largely stolen from BIND 9, although we can simplify quite a bit (hopefully).

Actually running the server will probably involve using a command line tool (BigTool program or a piece of it) to start the !AuthDNSQuery module and anything else necessary to do the work.

Depends on: A01, A02, A03, A04, A05 (maybe), A06, A07, A08, A09
Time estimate: 13w

  • Requirements documentation (including performance) (2w)
  • Design & developer documentation (2w)
  • Code (3w)
  • Tests (3w)
  • Benchmarks (2w)
  • Administrator documentation (1w)

Authoritative-Only Server Engineering Deliverables

These are non-programming tasks we need done for our release.

B01. Build farm

This is creating the build farm. Tests compilation and also runs unit tests.

Depends on: none

  • Design
  • Administrator documentation
  • Initial setup
  • Internal web publisher
  • External web publisher
  • Subversion integration
  • Additional build targets
  • External build targets

B02. Integration tester (separate from build farm?)

This is creating the integration tester. Performs other tests, probably including performance tests.

Depends on: none

  • Design
  • Administrator documentation
  • Initial setup
  • Benchmark setup
  • Internal web publisher (including benchmarks)
  • External web publisher (including benchmarks)

B03. Release engineering Pre-Year 1 (MILESTONE 2)

This is the release engineering work needed to build a working release, delivered before our Y1 final work.

Depends on: B01, B02

  • Automated release tarball checker
  • Lint, other mechanized code checkers
  • Release webpage design
  • Release e-mail templates
  • Tarball building
  • Documentation review
  • Webpage updates

B04. Release enginering Year 1

This is the release engineering work needed to build the final Y1 work.

Depends on: B01, B02, B03

  • Tarball building
  • Documentation review
  • Webpage updates

Year 2 Work

These are tasks that we would like to do in year 1, but are lower priority, so can be early tasks for year 2 if we don't have time to include them. These may also be good tasks for non-staff coders to implement, if they feel they are important for them.

C01. DDNS Module

The work involved with allowing DDNS updates. While not all data sources will support updates, the DDNS module needs to implement updates in a generic fashion for those that do. Beating BIND 9 performance is important, because it... could be better.

Depends on: [ wait until project progresses ]

  • Requirements documentation (including performance)
  • Design & developer documentation
  • Code
  • Tests
  • Benchmarks
  • Administrator documentation

C02. DCOMA Module (or DCOMA-like Module)

If the IETF does end up standardizing DNS control then we will need to implement that. Otherwise, implenting the functionality defined in the DCOMA requirements is probably a good idea too.

Depends on: [ wait until project progresses ]

  • Requirements
  • Design
  • Developer documentation
  • Code
  • Tests
  • Administrator documentation

C03. SQL Back-ends

This is both the generic and specific SQL data sources. We include two types of SQL data sources: one where BIND "owns" the SQL data and can do what it wants, and one where the underlying data can be changed at any time. We also need actual implementations for real SQL servers. We need at least one open-source one (probably !PostgreSQL) although two is better (probably also !MySQL). We will also want to implement Oracle, since at least one of the sponsors use it. We have a stage for improving the SQL performance, based on what we learned in the implementations. Re-factoring is highly likely to be needed to get things optimal. Finally, we review the API to make sure that it is sane after all this work.

Depends on: A07

  • BIND-owned Generic SQL implementation
    • Design & developer documentation
    • SQL schema
    • Code
    • Examples
    • Tests
  • "Free" Generic SQL implementation
    • Design & developer documentation
    • SQL bits (not really schema, but rules of interaction)
    • Code
    • Examples
    • Research into implications, including benchmarking
    • Tests
    • Administrator documentation
  • Open-source (!PostgreSQL? !MySQL? !SQLite?) implementation
    • Design & developer documentation
    • Code
    • Examples
    • Tests
    • Administrator documentation
  • Oracle SQL implementation
    • Design & developer documentation
    • Code
    • Examples
    • Tests
    • Administrator documentation
  • SQL performance improvements
    • Design & developer documentation
    • Code
    • Code re-factoring
    • Tests
  • API review
    • Updated documentation
    • Code modifications
    • Updated examples
    • Test modifications
    • Benchmark review

C04. SNMP Logging

This was moved to year 2, because it is an extension of existing functionality, and we are short of time.

Depends on: A03


Time estimate: 5w

  • Requirements documentation (3d)
  • Survey of existing technologies (1w)
  • Design & developer documentation (3d)
  • Code (1w)
  • Tests (1w)
  • Administrator documentation (3d)

Team

ISC:
MG  Michael Graff
EH  Evan Hunt
JR  Jeremy Reed
JT  Jinmei Tatuya
JJ  Jelte Jansen

JPRS:
KF  Kazunori Fujiwara
NK  Naoki Kambe

CNNIC:
C1  [ unknown ]
C2  [ unknown ]

Timeline

                         MG   JT   JJ   EH     KF  NK
2009-Q3
2009-w28                 A01  A06       
2009-w29                 A01  A06
2009-w30                 A01  A06
2009-w31  IETF 75
2009-w32                 vac  A06
2009-w33                 vac  A06
2009-w34                 A01  A06
2009-w35                 A02  A06     
2009-w36                 A02  A06  A03
2009-w37                 A02  A06  A03
2009-w38                 A02  A04  A03
2009-w39                 A02  A04  vac
2009-w40                 A02  A04  vac

2009-Q4 
2009-w41                 A02  A04  A03
2009-w42                 A07  A04  A03
2009-w43                 A07  A04  A03
2009-w44  BIND 10 team meeting (?)
2009-w45                 A07  A04  A03
2009-w46  IETF 76
2009-w47                 A07  A04  A03
2009-w48                 A07  A04  A03
2009-w49                 A07           <- ISC All Hands should be here (or w50)
2009-w50                 A07
2009-w51                 A07
2009-w52  Xmas week
2009-w53                 A07

2010-Q1
MILESTONE 1: running, non-functional server
2010-w01  
2010-w02
2010-w03
2010-w04
2010-w05
2010-w06
2010-w07
2010-w08
MILESTONE 2: running, functional server
2010-w09
2010-w10
2010-w11
2010-w12  IETF 77
2010-w13
END OF BIND 10 YEAR 1
Last modified 8 years ago Last modified on Aug 14, 2009, 9:27:20 AM