Opened 9 years ago

Last modified 3 years ago

#243 assigned enhancement

Put spec files together in source tree

Reported by: jelte Owned by: UnAssigned
Priority: low Milestone: Outstanding Tasks
Component: configuration Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket:
Total Hours: Internal?: no

Description (last modified by tomek)

Originally, the idea of the .spec file was to have one single thing that a new module could simply send to the configuration manager or other interested software pieces, that described what the module expects and can handle in terms of commands an configuration.

The idea was that on startup, it reads in this file, sends it to ConfigurationManager?, and all would be fine. However, we're running into a few snags.

One is that other modules might need a configuration value of another module (e.g. xfrin needs the location of the database_file from auth right now, this example may change in the future but there will probably be others). For that we have the add_remote_config() and get_remote_config_value() functions in CCSession.

However, since the only real fixed pointer to what may be in the config is this spec file, the module wanting data from another must have access to it. Which isn't necessarily a problem, but the location of the file might be when we run from source tree (in which case all spec files are in different locations, and we now end up with hardcoded src/bin/auth paths etc.).

Another thing that arised is that we might need to change configuration of modules that aren't running, and while we can do that now, there is no checking done on the values. If we wanted to do that, we'd have to hand-add all specfile locations or do some scary recursive directory search.

Therefore I propose to put *all* spec files in the source tree in one specific directory (like they would be when installed), so the manager can simply read all of them out, and the modules only need to know the file name, not the location.

This would also be a nice first step to have 'offline' access to these things (the API that loadzone would (perhaps indirectly) use for instance)


Change History (12)

comment:1 Changed 9 years ago by larissas

  • billable set to 0
  • Component changed from Unclassified to data source
  • Estimated Difficulty set to 0.0
  • Internal? unset
  • Owner set to UnAssigned
  • Priority changed from major to minor
  • Status changed from new to assigned

comment:2 Changed 9 years ago by larissas

  • Milestone set to feature backlog item

comment:3 Changed 8 years ago by stephen

  • Milestone feature backlog item deleted

Milestone feature backlog item deleted

comment:4 Changed 8 years ago by shane

  • Defect Severity set to N/A
  • Milestone set to New Tasks
  • Sub-Project set to DNS

I'm not sure about this one. What do we do about out-of-tree modules, and so on?

Did this get discussed on bind10-dev or within the team? I don't remember it, if this was discussed maybe you can dig up a pointer. If not, perhaps something on bind10-dev is appropriate?

comment:5 Changed 8 years ago by shane

  • Component changed from data source to configuration
  • Milestone New Tasks deleted
  • Owner changed from UnAssigned to jelte

comment:6 Changed 6 years ago by jelte

  • Owner changed from jelte to UnAssigned

This should be addressed in a more general config framework redo

comment:7 Changed 5 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:8 Changed 4 years ago by tomek

  • Milestone changed from Remaining BIND10 tickets to Kea1.2

comment:9 Changed 3 years ago by tomek

  • Description modified (diff)

Bringing spec files up to date will be a large task. We may consider the alternative - rewrite them as YANG models. The benefit of using YANG syntax is obvious. There are many tools that allow manipulation and processing of YANG models. Also, if/when we integrate YANG/NETCONF support, such a model would be invaluable.

Also, see

comment:10 Changed 3 years ago by tomek

  • Milestone changed from Kea1.2 to Kea-proposed

comment:11 Changed 3 years ago by stephen

  • Milestone changed from Kea-proposed to Outstanding Tasks

Moved to outstanding, decision of Kea call on 2016-10-13

comment:12 Changed 3 years ago by fdupont

We have grammars which should replace .spec files. I propose to close this ticket.

Note: See TracTickets for help on using tickets.