[kea-dev] Hooks libraries and configuration information

[Stephen Morris]

On 01/09/2015 19:22, Thomas Markwalder wrote:
> On 9/1/15 12:51 PM, Stephen Morris wrote:

> I know you are trying to avoid overlap, but hooks writers are likely to
> be fond of being able to get right to their parameters without having to
> trip over any others, regardless of how we do it.  If we don't hand them
> the parameters at load time, then I think they would appreciate at least
> a shortcut "getMyParameters()" method which returns them a map
> containing only their parameters.   I do not think their going to want
> to navigate their way down to them and then sift based on prefixes.  
> Visually I think specifying the parameters within the hooks element is
> the most concise way to go.
> I don't think providing a convenience method while also being able to
> navigate them to them is that much overlap.
> 
> It is possible that a user might deploy libraries from more than one
> author,  each of whom may employ their own notion of a naming scheme. so
> we would at least need to document a prescribed a naming policy.   If
> you still feel they should be seperate from the hooks element, an
> alternative might be to add an optional named parameter set to each hook
> lib along with the library itself:
> 
> {
> "Dhcp4": {
>   :
>     "hooks-libraries" : [
>         { "library" : "/opt/charging.so", "parameter-set" : "charging" },
>         { "library" :"/opt/local/notification.so", "parameter-set" :
> "notification"}
>     ],
> 
>     "hooks-parameters": { 
>         "charging" :   
>             {
>               "alpha": "beta",
>               "foo": "bar"
>             }
>        ,
>        "notification" : 
>             {
>               "param1" : "value"
>             }
>     }
> 
>  :
> }
> }
> 
> This would still avoid passing the parameters at start time yet give you
> guarantee-able segregation.  One would have to pass the hook its name at
> start up, but fetching the actual parameters would be no different than
> navigating to any other configuration value.  It would also make it
> possible for libraries from the same author to use the same parameter set.

I don't see any restriction in the types of parameters that can be
passed to libraries, so having hooks-parameters as a map, each map
identifying the parameters for a particular library certainly fits in
with the requirements as stated (although it does mean that requirement
6 is now mandatory instead of being a "nice to have").

You idea of having the library specification point to a parameter set is
a good one. There shouldn't be too much overhead including a
getMyParameters() function as it is effectively little more than a call
to
getParameters("<my-kea-component>/hooks-parameters/<my-parameter-set>").
All that is needed is for the system to associate the correct component
and parameter set name with each library when the configuration is read,
and that should be relatively easy to do.

Having said that, it does mean that it is not so easy to obtain the
configuration information for a given library through the general
mechanism, as you need to know where in the library list the library in
question is, and from that identify the parameter set name.

However, if we allow for a getMyParameters() call, there seems no reason
why we couldn't allow something like:

{
  "Dhcp4": {
       :
    "hooks-libraries" : [
      {
        "library" : "/opt/charging.so",
        "parameter-set" : {
           "alpha": "beta",
           "foo": "bar"
        }
      },
      {
        "library" : "/opt/local/notification.so",
        "parameter-set" : {
          "param1" : "value"
        }
      }
    ]
  }
}

This does have the advantage of keeping the parameters close to the
library.  Again though. it is awkward to obtain the parameters via name.

I think that the right solution might be to allow both forms, and layer
the "getMyParameters()" on a general configuration access mechanism.

Stephen