Opened 17 months ago

Closed 4 weeks 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 17 months 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 14 months 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 12 months 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 12 months ago by tomek

  • Milestone changed from Kea 1.4 to Kea1.4

Milestone renamed

comment:5 Changed 8 months 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 8 months ago by tomek

I think these methods should go to libprocess.

comment:7 in reply to: ↑ 6 Changed 8 months 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 5 months 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 4 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 4 weeks 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.