Notes from BIND 10 team conference call.

Date: 2009-12-03 Minutes: Shane


On Thu, 2009-12-03 at 15:12 +0100, Shane Kerr wrote: 
Jeremy spent some time thinking about the agenda for today's call, and
listed some possibilities in the Jabber room.

>       * Roll call
>       * Status checkpointing:
>               * DNS message API

Checked in with new style.
Completing name class with this style.

Shane: so when this style is done then it will be ready for review and
end-user use?
Jinmei: open question - how this will be done
Shane: ISC way is that someone else on the team reviews... review each
part or entire package?
Jinmei: have name class reviewed when completed, and then each class
as it is done... otherwise reviewed part is very large
Shane: don't want review to go to list and sit without knowing who is
responsible... contact me and we'll figure out who is the best person
Jinmei: any tools...?
Shane: ticket system from Trac site should be good enough

AP: Shane to write ISC review process and put it on the Wiki

              * c-channel
Michael: re-wrote msgq in Python... slow in comparison to C version
(about 1/25 the speed)... implements all the features we need it.
Minor change to way messages are delivered... messages addressed to
person are always delivered.
Jelte: new wire format?
Michael: message now encoded separately - not in header
Shane: no change to API?
Michael: no change to API!

Shane: language issues, how widely accepted?, think we should use the
msgq stuff for now, and maybe change later...
Michael: tend to agree

Shane: status?
Michael: cooked
Shane: ready for review, then move into main trunk?
Michael: code is kind of wacky... some changes would like to make...
maybe note those and submit for review... some unit tests!
Shane: try to wrap it up...
Michael: will add TODO... then ready for review
Jelte: will do review

Jelte: also... Python 3.1? Didn't we fix stuff to work with 3.0?
Shane: we'll stick with 3.1

              * Configuration

Jelte: committed a few things today, invading on BigTool territory, so
using own branch for now.
1. positional arguments, rather than named arguments
2. bigtool can edit configuration as defined by configuration file
Seems to work!

Can then merge into parking lot, then ready for review. 

Lots of open issues... in BigTool can add value to a list, but no wire
protocol for that, not sure if I should make it.

Shane: note them, then move on!
Jelte: expect to be finished & merged next week, but all hands will
reduce productivity

              * BigTool

Likun: 2 points... almost finished code about login to Command &
Control module... want to commit next week... prefer to use XML-RPC to
communicate between BigTool and C&C module. REST is probably not
usable... too complex. Need to install some HTTP server on command
module. For first version prefer to use XML-RPC.

Michael: NO! Please don't!!! XML-RPC is okay, but would rather not
complicate things with an RPC layer. Would rather see a simple HTTP
server than use REST if we can avoid it. 

Likun: Only message is for the command. So I think it is not very
difficult if we have new commands to support.

Jelte: Maybe we have different ideas about what these things were
going to do.
Michael: I thought we were just going to use the msgq library...
Shane: no, not in this way...
Feng: could also use JSON or something else...
Michael: REST-ful interface has a certain feel to it.

AP: Michael to mail link with PDF for the DLV web site, which uses
REST-ful interface. Wikipedia is probably best to start with.

Michael: Must be a simple way to do this
Shane: There is a http.server class in Python...
Likun: will commit code and send to Michael for review. ;)

Likun: command line syntax mentioned by Paul
Shane: I have a call set up with Paul today to find out what he means

[ some discussion about UI design ]

              * Stats
Kambe: investigating PySNMP library

Jeremy: I was just curious, didn't look at code in there, was
wondering how it will tell other components what it will receive. Do
we have this listed out? Is it using the command channel? I assume it
is. How we are going to keep track of this and how we are going to
share it. Maybe we need to start a wiki page?
Shane: None worked out.
Jeremy: Assume all things will have statistics.
Michael: Everything has something that it does. Even the stats server
has stats.

AP: Jeremy to add page to Wiki about this.

Jeremy: Will use command channel for communication?
Michael: that is the plan

              * BoB
Shane: TODO file created.
Jelte: Please commit the TODO file, there may be other things to add
to it.

* Progress, dependencies, time estimates:
Jeremy: What is our actual progress. Can we discuss that?

Shane: main items are: 1) data source, 2) everything else... ISC
coders looking at data source now, Evan and these will look at
"everything else" ASAP... schedule not (yet) in jeopardy

Jinmei: possible to convert timeline to graphical output?
Shane: like a Gannt chart? Sure...
Jinmei: easier to understand graphically
Michael: look at graphviz...

AP: Shane to try to make a graph of this

      * First public deliverable

Jeremy: AS112 server. Wiki page called "first release" which lists the
components for that.
Jeremy: please look at this, then timelines, then we need some other
things done... for example, parking lot used wrong API for efficiency
in speed, some developers to look into that part
Jelte: on most levels as far as we can take the whole system without
having the data source... does need quite a bit of work on some
fronts, I agree
Shane: should we go over this face-to-face next week? Good use of time?

Jeremy: can create documentation for operator to install and turn
on... should be short & sweet since this is simple! I could also edit
the parking lot so it provides the zones we want to serve... should be
easy since that is just NS records.
Michael: AS112 document hasn't been changed since May 2003 and
recommends using BIND 8!

Hankins: folks who observe AS112 in the wild think it is an attack...
so if there is anything untoward in this server's output it might make
people's jobs hard if they have weird output
Michael: would be nice to have a packet capture of AS112 traffic
Shane: Do you know if we have a separate server for this?
Hankins: I think it is a separate server... is on a separate address
Michael: we could have a separate one, since this is anycast...

Michael: when will F root run this?
Hankins: 2012?
Shane: that *is* the date I picked for "general release"...

      * Official name of BigTool

Jeremy: I didn't know that was the real name...
Michael: it's the working name...
Jelte: I like "BIND Control"...
Michael: me too
Shane: is that bind-control?
Jelte: don't care...
Michael: don't care... could even be bind-ctrl
Jinmei: bind-control is more clear, but my general impression is that
"BIND control" sounds like just a command line tool rather than an
interactive session. Is that only me?
Michael: I think it would be both.

Hankins: Are you talking the command line invocation name? Needs to be
very nice and short. "rndc" and "nsdc" are both good examples. 
Michael: bindctl
Hankins: a little wordy... prefer bctl
Jelte: hated zonec because it didn't have "nsd" in it

We like "BIND Control" but we don't know how to spell it.

Feng: why not use rndc?

      * "user" installation/usage documentation

Jeremy: In Docbook format for each component, was going to provide a
description of usage, and then provide some shell scripts to render
those into man and HTML.

Michael: needs to be simple for first release, prefer install guide
and a "detailed" install guide (if necessary)

* data source

No time... sorry!

      * Next week's call

AP: Shane to propose a new time for the call.


Hankins: time to get thoughts together about DHCP, will write rough
draft about what the problems are, then we can talk about solutions

Shane: bye... will see most of you next week! 
Last modified 9 years ago Last modified on Dec 8, 2009, 4:47:59 PM