wiki:SprintPlanningDHCP20120222

DHCP Sprint Planning Meeting: 2012-02-22

Attendees

Larissa
Shane
Shawn
Stephen
Tomasz

Requirements

Shawn had reviewed the current requirements and felt that the DNS issues were perhaps over-engineered. We did not need to guarantee that DDNS succeeded, we only needed a best effort approach as there are always ways we can fail. We do not need to track key and server for each update.

We also need to sort out what happens to associated DNS information if we remove a pool. We could:

  • Remove all information from the database, ignoring any information in DNS
  • Leave the DNS information in the database and allow the code to remove it from DNS as the lease times out.
  • Actively issue removal requests for the DNS information.

We should give the user options. (It is for reasons like this that the use of administrative tools - rather than just have SQL access to the database - was envisaged.)

Tomasz has updated the requirements and it is now up for re-review. Shawn will review and add comments to the associated ticket (#1634).

Past Sprint

Completed one ticket (#1633, fix for OS/X Lion). As well as #1634 (requirements), two more are in review state: #1528 (Linux interface detection refactoring) and #1540 (general code refactoring). #1651 (Integrate DHCP process startup into BIND 10) is actively being worked on.

It was commented that the document does include some design work, which is really part of #1648. This is perhaps inevitable - when the requirements are complete, the design will be split out into a separate document and completed.

Note that the refactoring tickets #1282 and #1295 have been done as part of the main refactoring work (#1540) and will be closed when that one is closed.

This means that the only ticket not really started is #1609 (review of object breakdown) and that is waiting for #1540 to be completed.

Next Sprint

Need to get requirements and design finished before we can really start on the 2012 work. So focus for this sprint will be completion of the requirements (#1634) and bug-fixing.

All existing tickets were taken through, although there was one modification: #1651 (Integrate DHCP process startup into BIND 10) would be renamed "Integrate DHCP process startup into BIND 10" and a separate ticket created for the DHCP6 work.

Other tickets selected were:

  • #1281 - make distcheck fails
  • #1301 - dhcp and IfaceMgr creation failed

#1485/#1486 (IOAddress issues) were considered in light of comments by Jinmei. It was observed that the socket handling in BIND 10 DNS is quite simple, whereas DHCP requires more low-level access to the sockets and needs to make a distinction between V4 and V6 sockets. From this it was concluded that use of the IOAddress class was not best for DHCP, and that something else would be needed. A ticket would be added to come up with a proposal for alternatives (which is likely to result in these tickets being withdrawn).

Note added after meeting: #1709 has been created for this.

  • #1503 - specify port number on V4 and V6 daemons. Ultimately this information will come through the configuration channel; for now though, the change is needed for testing.

(Discussion of this ticket led to discussions regarding keeping the footprint small (i.e. not using the configuration daemon) - clients are a particular problem. However, it was agreed that we need to get things working first and that the small footprint work can come later.)

  • #1545 - use BIND 10 logging
  • #1531 - write documentation for libdhcp++

AOB

Blog

Once we have agreed on the requirements, we should write a blog article and ask people to comment.

Comcast Meeting

Larissa will help organise meeting with Comcast at IETF-83 to discuss work to date.

Work in a Future Sprint

Shawn has been considering the implications of our hooks proposal and how a user would use it to control the address given to a client. Although the callout could interact with the pool database, Shawn felt that a better way would be for the callout to select a class based on the contents of the packet, then have the main code consult a pre-configured class list and select the address based on that.

This bypasses issues such as the callout returning an address that the server is not responsible for. And although we could leave in the option of address selection, we could strongly recommend that it is not the desired way to do things.

Note added after the meeting: Action - Shawn to add suggestion to list of open questions on the hooks page.

Last modified 6 years ago Last modified on Feb 23, 2012, 12:58:41 PM