wiki:DhcpWorkflow

DHCP in BIND10 workflow

This page describes DHCP in BIND 10 workflow proposal.

DHCP in BIND10 implementation is about to start. Here is a proposal on how to organize the work. Primary goal is to minimize impact of DNS changes on DHCP work and vice versa, while keeping overhead as low as possible. Another goal is to propose architecture, that will be extensible, but will allow running DHCP server will limited functionality soon.

Branches

Similar to what already is happening in bind10 will work best. There are 2 possible approaches: Proposal: Branch per ticket. DHCP developer gets a ticket, makes ticket branch, checks in the code, goes thru review and then checks into master

  • pros: excatly the same as in bind10; we can reuse existing bind10 validation approach
  • cons: bad dhcp checkin may destabilize master

Alternative: We may create dedicated dhcp branch. DHCP developer gets a ticket, makes ticket branch, writes and check ins the code, then goes through a review and then checks in to DHCP. DHCP branch is periodically merged into master

  • pros: dhcp changes will not impact bind10 core and DNS stability
  • cons: extra recurring cost (dhcp merge); merge may be difficult if not done often

Sprints

dhcp sprints may be aligned with bind10 or in anti-phase (shifted by 1 week). Proposal: dhcp and bind10 aligned

  • pros: easier for schedule planning ("3 sprints till release")
  • cons: increased workload around sprint ends

Alternative: dhcp and bind10 in antiphase

  • pros: smoother development (a sprint ends every week)
  • cons: last sprint will not be aligned with release

Probably proposal is better than alternative, if Shane can handle increased workloads during sprint ends.

Releases

Similar to sprints alignment problem. Proposal: aligned - both dhcp and bind10 dns have release at the same time

  • pros: clean maintenance, no dependency problems for
  • cons: none?

Alternative: not aligned

  • pros: none?
  • cons: dependency problems

It is strongly recommended to release both components together to avoid dependency problems after code is released. This code is going to be used be many users. Frustrated users trying to find out which DNS and DHCP components are supposed to match may not be the best way to go.

Reused modules

List of modules and features from dns and bind10 core that could be reused for dhcp10:

  • b10-msgq - communication channel. Every modules must use it
  • b10-cfgmgr - every module needs it, required for obtaining configuration and also notifications for configuration changes. I think we will use hardcoded configuration for next several months, but we still need at least a dummy configuration getter.
  • stats - DHCP will offer stats eventually, but it is not high priority during the initial phases

Proposed modules

See also DHCPComponents that contain more fine grained features. Probably those two lists should be merged.

  • libdhcp - utility library, message/option parsing, encapsulation (relays in v6), sanity checks protocol correctness (missing mandatory options, extra options), etc.
  • b10-ifaces - interfaces and system access abstration layer. Something that will provide list of network interfaces, will receive and send data, possibly detect interface changes (like link switch, necessary for client's confirm), execution of external scripts (if we choose that); provide list of addresses (MAC/IPv4/IPv6) configured on network interfaces, probably several slightly different socket interfaces (Linux/BSD/solaris).
  • b10-dhcp4 - core DHCPv4 protocol logic (e.g. generate responses)
  • b10-dhcp6 - core DHCPv6 protocol logic (e.g. generate responses)
  • b10-dhcp-be - First database backend. It will be implemented as in-memory DB, as it is in DHCP4 now.
  • b10-dhcp-be-ldap - database backend - data is kept in LDAP
  • b10-dhcp-be-{psql,mysql,sqlite,whatever} - data kept in SQL db
  • b10-dhcp-be-ddns - a module for doing DNS Updates
  • b10-dhcp-failover - a module for doing failover (possibly 2 modules: failover4 and failover6)

I think that the first proof-of-concept prototype of DHCP in BIND10 implementation should cover at least the following modules:

  • libdhcp - at least a skeleton version, probably will not parse or build anything, but at least provide API
  • b10-dhcp6 - we should start with DHCPv6 as its implementation is simpler; there is no socket funkyness, no backward compatiblity with bootp, no message validation with icmp etc. The only (minor) difficulty is the need to bind multicast (a single setsockopt will do the trick).
Last modified 6 years ago Last modified on May 30, 2011, 6:05:04 PM