Opened 2 years ago

Last modified 22 months ago

#5516 new enhancement

Design a mechanism to define options in hook libs

Reported by: tomek Owned by:
Priority: low Milestone: Kea1.x
Component: hooks 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 are several use cases where it would be useful to have option definitions being defined in hooks. Here are couple examples:

  • RADIUS hook that introduces radius options with many suboptions
  • DOCSIS hook that has tons of vendor options with some extra logic to handle them
  • PXE hook that does extra PXE magic (and handles PXE options, see for an example list)

The goal of this ticket is to come up with a mechanism that lets do this. Requirements (they may change, this is just an initial list):

  • option definitions in hooks.
  • the definitions become usable once the hook is loaded
  • the definitions stop being usable once the hook is unloaded

This may impact how the hook libraries are loaded during configuration. It seems likely that we will need to load the hooks first before we parse/apply the remaining configuration structures.


Change History (4)

comment:1 Changed 2 years ago by fdupont

Some questions/comments:

  • why is it a defect? (IMHO to looks more like an enhancement)
  • is it about option definition (*), option data or both?
  • for option definitions I really prefer to have them in the config file so for instance I don't have to read code to find the definition. If we need a manage a library of option definitions we have the include feature.
  • for option data the current class mechanism seems to be enough and more coherent.

I have a concern about the last point (load order) because hook DSOs are loaded at the end for good reasons.

(*) I have a proposal: to allow to have more than one option-def in a config and when it happens just add new entries in the list. This can be applied to some other lists and can be done at the same time the parser raises an error when something is defined more than once (today the last entry silently erases previous entries).

comment:2 Changed 2 years ago by tomek

  • Milestone changed from Kea-proposed to Kea1.4
  • Summary changed from Design a mechanism to define options in hooks to Design a mechanism to define options in hook libs
  • Type changed from defect to enhancement

comment:3 Changed 22 months ago by tomek

  • Priority changed from medium to low

comment:4 Changed 22 months ago by tomek

  • Milestone changed from Kea1.4 to Kea1.x

Moving to 1.x as discussed on 2018-05-10 call.

Note: See TracTickets for help on using tickets.