Opened 3 years ago

Closed 20 months ago

#5263 closed enhancement (complete)

Common CPL/Dhcpsrv-Daemon framework

Reported by: tomek Owned by:
Priority: medium Milestone: Kea1.5
Component: configuration Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


There's significant overlap in functionality between CPL architecture (libkea-process) and DHCP components (libkea-dhcpsrv). This was cause of many issues and duplicated work.

See #5253 for example (CA stores its own configuration in a different place than logging configuration, causing the code to extract configuration from two places).

Also, the libprocess dependency on libdhcpsrv is insane. We should move some parts of the code from libdhcpsrv (Daemon for sure, but perhaps CfgMgr? as well after making it more general) to libprocess and remove the dependency.


Change History (10)

comment:1 Changed 3 years ago by tomek

  • Milestone changed from Kea-proposed to Kea1.3

Moving to 1.3 as these are necessary follow-ups for 1.2 ("technical debt").

comment:2 Changed 3 years ago by tomek

Part of that work has been conducted during IETF99 Hackathon in Prague. See The changes cover the following:

  • split CfgMgr? into dhcp::CfgMgr? and process::BaseCfgMgr?
  • moving most generic stuff from dhcpsrv to process
  • remove libprocess depedency on libdhcpsrv
  • add libdhcpsrv dependency on libprocess
  • Now both DHCP servers and CPL architecture uses the same base class for storing configuration: process::BaseConfig?.

During the hackathon we worked on a prototype client implementation. This was a good opportunity to think about how to reuse existing code to create a new service. Here are my thoughts.

  1. CPL architecture is better in overall process management. The controller, despite its odd name (DControllerBase), provides nice encapsulation and good interface.
  2. dhcp::CfgMgr? provides better configuration management with staging and running config, and some provisions for keeping X old configurations and revert. Those two last features are not functional yet, but the code is there.
  3. dhcp::SrvConfig? provides the only way to store logging information. This was moved to process::BaseConfig? in the client repo.
  4. It seems clear that the project is moving towards using async communication more are more. CPL does use it exclusively, while dhcp does a mix of async (IOService) and sync (select, sendmsg). We should migrate dhcp to full async operation.

comment:3 Changed 3 years ago by tomek

  • Milestone changed from Kea1.3 to Kea 1.4

As discussed on 2017-09-14 call, there is not enough time for this and it's too intrusive to be done after beta, thus deferring to 1.4.

comment:4 Changed 2 years ago by tomek

  • Milestone changed from Kea 1.4 to Kea1.4

Milestone renamed

comment:5 Changed 2 years ago by fdupont

When replacing libkea-dhcpsrv by an empty library these symbols become undefined:


so I am in favor of a quick experiment moving daemon code to its own library...

comment:6 follow-up: Changed 2 years ago by tomek

I think these methods should go to libprocess.

comment:7 in reply to: ↑ 6 Changed 2 years ago by fdupont

Replying to tomek:

I think these methods should go to libprocess.

=> if we do this the immediate effect will be to add another dependency to dhcp servers. I know there will be some benefits at long term but not at short term and this clearly adds arguments to postpone this ticket...

comment:8 Changed 2 years ago by tomek

  • Milestone changed from Kea1.4 to Kea1.4-final

As discussed on 2018-04-26 call, moving low and some med priority tickets to 1.4-final.

comment:9 Changed 23 months ago by tomek

  • Milestone changed from Kea1.4-final to Kea1.5

That's definitely not appropriate to do make this kind of changes in final. Moving to 1.5.

comment:10 Changed 20 months ago by tomek

  • Resolution set to complete
  • Status changed from new to closed

This ticket now lives in gitlab:

Note: See TracTickets for help on using tickets.