wiki:SprintPlanning20110802

BIND10 Sprint Planning Meeting - 12 July 2011

Present

Aharen
Dima
Fujiwara
Jelte
Jeremy
Jerry
Jinmei
Kambe
Larissa
Likun
Michal
Shane
Stephen

Review of past Sprint - Technical

(Organisational review deferred until next planning meeting owing to anticipated amount of work in this meeting.)

Where are we with the goals of the sprint:

Decide on replacement for message queue
Done for now - decision deferred until F2F. There is a page summarizing the findings so far at http://bind10.isc.org/wiki/msgqReplacements

Start on data source refactoring
[ will be discussed later in meeting ]

Add TSIG ACL
Jinmei: Code ready, minor open issues. Scheduled work was done.

Stephen: Tickets created for open issues?

Jinmei: Not yet... was proposed. Will create them.

Jinmei: Cannot configure per-zone. (Single ACL for all incoming XFR requests.) Not what we eventually want. Don't know our plan to include that.

Michal: Problem of xfrout that there is no per-zone configuration. xfrout needs redesign.

Shane: Other per-zone config needed for xfrout?

Jinmei: Several. Per-zone resource configuration, for example.

Michal: Problem is xfrout acts the same for all zones.

Stephen: But what about restricting queries for a zone to a single IP address?

Michal: We are far from that design.

Likun: Can we check the config per zone on BIND 9?

Jeremy: BIND 9 can restrict queries per-zone.

Shane: I think queries is not strictly required.

Stephen: We can generalize and restrict for all aspects of BIND 10.

Shane: But for XFR I think that it is required.

Jinmei: I think we can handle it via a kind of quick hack to xfrout.

Jinmei: Also b10-resolver also does not support TSIG based ACL, since there is no configuration mechanism. But I think it is a relatively minor point.

Shane: Probably not used much outside of Windows environments.

Jeremy: Can ops use this by reading our docs?

Jinmei: It's not documented I suspect.

Extend RR types supported
Jeremy: we need ChangeLog entries.

Socket creator
Michal: Started by the boss process, and the boss can ask for a socket. No way to ask the boss for a socket. API ticket in review.

Extend statistics
Jelte: Reviewed some of the tickets. First 2 are ready but will be merged along with the 3rd is done. (#928 #929 done, #930 being done)

Sprint Planning

Year 3 release 3 goals

  • DDNS
    • New model for writing to data sources
  • IXFR-out
    • New model for writing to data sources
  • IXFR-in
    • New model for writing to data sources
  • High-performance data source
    • Refactor of data sources
    • Profiling of refactored data sources
    • Performance improvements to existing data source done
    • Update NSD-inspired prototype to match refactored code
  • msgq replacement
  • All RRTYPE codes implemented
  • Socket creator completed
  • b10-auth use multiple cores
  • Equivalent of "rndc reload" and other such commands for in-memory data source(s)

Data Source Refactoring

  • How advanced is it?
  • Is the task list complete
  • What are the dependencies between tasks - can we work on them in parallel?

Jinmei: We have just started it, no so much progress yet.

Michal: In-memory data source is similar in the new model, so it is ready, but the definition for database data source is slowly moving to something.

Stephen: How well defined is the work to be done?

Michal: Looks to be described pretty well.

Jelte: I took last ticket planned for this sprint. I have a pretty good idea too.

Shane: Tickets #1063 to #1068.

Jinmei: Current tickets do not include IXFR or dynamic updates.

Jinmei: Once we have a framework for writeable tickets, we will probably need 5 or so tickets before starting ixfr-in. For ixfr-out we will probably need more, because we need to have another framework to identify the appropriate difference between 2 versions of zone.

Stephen: Add task with design work for data source differences (base for IXFR), 2nd task further breakdown of data source refactoring.

Stephen: For multiple cores, we need serious design work.

Michal: Did we make a decision? Decision won't affect the API.

Stephen: But we need the implementation as well!

Jinmei: For the moment we don't have to worry about implication of multiple core. When we worry about IXFR or DDNS we need to worry about implications.

Shane: We are hoping to have IXFR-in and IXFR-out in Y3 release 4 (2011-10-11).

Jinmei: We have some vacation, we have face to face meeting, we have ISC all hands meeting. There are many kinds of distractions. We are always optimistic, so combining all of these I suspect it is unrealistic.

Stephen: Do we need to make a decision about multiple cores this sprint?

Shane: Probably not necessary but I think we can. So we should.

What tasks do we carry forwards?

More or less all of them.

What tasks do we add?

  • #1063 to #1068
  • New ticket: Design work for data source differences
  • New ticket: Further breakdown data source refactoring
  • Can pull in RR type tickets (4)

Stephen: How urgent is socket creator?

Michal: Needed for multi-core, and also for production.

Jinmei: If we consider IXFR top priority we don't have time for socket creator, however if we consider IXFR too big for next release we might do socket creator instead of IXFR. Then we can say "BIND 10 can now be run as change user". (Next is Y3 release 4)

Stephen: Before we start IXFR we have a design cycle, so it won't be started until the sprint after this one.

Socket creator comprises tickets #802 to #805

Shane: If we have to choose, IXFR is higher priority.

Michal: socket creator is independent of refactor work, but they are perhaps both big tasks

Stephen: Lets defer socket creator for now, but we can discuss it at our meeting next week. We should have estimates then, and we will have tickets needed for data source refactoring.

Tidying up Next-Sprint-Proposed

Bug fix tickets

Jinmei: #904 will be needed for RTYPE support

What about statistics tickets?

Aharen: #509 ready for review, #510 almost done (internal review), #511 stopping on working because ticket requires list all zones in data source (waiting for data source refactoring)

Aharen: In next sprint #510 will be finished.

Jinmei: In general statistics tickets are too big for review. Subsequent statistics tickets should be sufficiently small so we can more easily review them.

Stephen: Statistics tickets at face to face?

Shane: Agreed.

Any Other Business

DHCP code review

Jinmei: Only 2 DHCP developers, or will review be done by all developers. And if so will we include that in our sprint planning?

Stephen: I was going to raise at the DHCP meeting. At the moment only Tomek has C++ knowledge, but Shawn wants to learn it, and we potentially have a new hire who wants to learn C++. What I was thinking is that DHCP tasks in BIND 10 will be reviewed by myself or Shawn and we will see how that goes for the next sprint or so. If we cannot cope we can involve the rest of the BIND 10 team.

Jinmei: Will also be nicer if we have some level of interaction so we can be familiar with each others' work.

Stephen: I agree but we have a lot of tight timescales.

Jeremy: Please also include documentation in the review process, and also ChangeLog entries.

Jinmei: Probably all of us forget the contents of the documented procedure. Or new ones may not have ever known in the first place.

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

Jeremy: Sometimes user documentation may be too big for the ticket. In that case, create a new ticket.

Last modified 6 years ago Last modified on Aug 2, 2011, 5:36:49 PM