Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Hooks libraries and configuration information (Stephen Morris)
2. Re: Hooks libraries and configuration information
(Thomas Markwalder)
3. Re: Hooks libraries and configuration information
(Stephen Morris)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 Sep 2015 17:51:48 +0100
From: Stephen Morris <[email protected]>
To: [email protected]
Subject: [kea-dev] Hooks libraries and configuration information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Plans for Kea include the extension of the hooks capability, in
particular the provision of a way for configuration information to be
passed into hooks code. This email opens a discussion about the form
this access should take.
We currently have two tickets in Trac for the passing of configuration
information to hooks libraries:
#3259 - Need ability to pass configuration parameters to hook libraries
#3456 - Hooks should be able to access current configuration
The idea of #3259 was that in the specification of the hooks libraries,
it would be possible to specify library-specific configuration
parameters. At the moment, the hooks libraries are specified as follows:
"Dhcp4": {
:
"hooks-libraries": [
"/opt/charging.so",
"/opt/local/notification.so"
]
:
}
It was envisaged that this would be extended to something like:
"Dhcp4": {
:
"hooks-libraries": [
[
"/opt/charging.so", {"alpha": "beta", "foo": "bar", ...}
],
[
"/opt/local/notification.so", {"param": "value", ...}
]
]
:
}
In other words, each hooks library is passed a map of name/value pairs
associated with it, probably somewhere during the library
initialization. It would be up to the library to store the information
for later use.
Ticket #3456 was created later on when it was realised that it would be
helpful for the hooks libraries have access to the general
configuration. For example, it could be useful for a server's hook
library to be able to know what address pools the server is configured with.
There is a clear overlap here, as general access to the configuration
would also allow access to the hooks libraries parameter lists. It seems
pointless to provide two means to get the same information, so a joint
approach to the tickets is indicated. The first step is to draw up the
requirements for such a system and the following are proposed as a start
to the discussion:
1. No information is explicitly passed to the hooks libraries during
their initialization. Instead, they are able to access parameter
information by reading the configuration.
2. Rather than include library-specific parameters as part of the
"hooks-libraries" element, a separate "hooks-parameters" map is
included. This holds parameters for all libraries, it being up to the
library author to adopt a naming scheme to minimise clashes, e.g.
"Dhcp4": {
:
"hooks-libraries": [
"/opt/charging.so", "/opt/local/notification.so"
],
"hooks-parameters": {
"charging-alpha": "beta",
"charging-foo": "bar",
"notification-param", "value"
}
:
}
(The above example prefixes parameter names with the name of the
library, but any scheme could be used.) True, there is the possibility
of a name clash between libraries, but realistically that chance is
small if some form of prefix scheme is used in naming.
3. It should be possible for hooks libraries to determine the component
of Kea in which they are running. To explain this, at the top level,
the Kea configuration file is a JSON map of the form:
{
"Dhcp4": {...},
"Dhcp6": {...},
"DhcpDdns": {...}.
"Logging": {...}
}
It is feasible that a general-purpose library might be written that
could be included into more than one component. In that case, it needs
to know the component in which the configuration for that particular
instance is included.
4. The configuration access interface should allow access to data
through a simple naming scheme, e.g.
Dhcp4/hooks-libraries[0] = "/opt/charging.so"
Dhcp4/hooks-parameters/charging-alpha = "beta"
(BIND 10 used slashes to separate components, but we can choose another
separator.)
5. The configuration interface should:
a. Allow counts of elements in lists and maps to be returned.
b. Allow iteration over the elements of a list and a map.
6. Depending how sophisticated we want to get, the interface should
allow sub-trees of the configuration to be passed around. For example,
accessing "Dhcp4/hooks-parameters" should return a subtree representing
the map of parameters. With this as the data on which the parser
operates, accessing "charging-foo" (rather than
Dhcp4/hooks-parameters/charging-foo) should return the value "bar".
Thoughts?
Stephen
------------------------------
Message: 2
Date: Tue, 1 Sep 2015 14:22:04 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Hooks libraries and configuration information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 9/1/15 12:51 PM, Stephen Morris wrote:
> Plans for Kea include the extension of the hooks capability, in
> particular the provision of a way for configuration information to be
> passed into hooks code. This email opens a discussion about the form
> this access should take.
>
> We currently have two tickets in Trac for the passing of configuration
> information to hooks libraries:
>
> #3259 - Need ability to pass configuration parameters to hook libraries
> #3456 - Hooks should be able to access current configuration
>
> The idea of #3259 was that in the specification of the hooks libraries,
> it would be possible to specify library-specific configuration
> parameters. At the moment, the hooks libraries are specified as follows:
>
> "Dhcp4": {
> :
> "hooks-libraries": [
> "/opt/charging.so",
> "/opt/local/notification.so"
> ]
> :
> }
>
> It was envisaged that this would be extended to something like:
>
> "Dhcp4": {
> :
> "hooks-libraries": [
> [
> "/opt/charging.so", {"alpha": "beta", "foo": "bar", ...}
> ],
> [
> "/opt/local/notification.so", {"param": "value", ...}
> ]
> ]
> :
> }
>
> In other words, each hooks library is passed a map of name/value pairs
> associated with it, probably somewhere during the library
> initialization. It would be up to the library to store the information
> for later use.
>
> Ticket #3456 was created later on when it was realised that it would be
> helpful for the hooks libraries have access to the general
> configuration. For example, it could be useful for a server's hook
> library to be able to know what address pools the server is configured with.
>
> There is a clear overlap here, as general access to the configuration
> would also allow access to the hooks libraries parameter lists. It seems
> pointless to provide two means to get the same information, so a joint
> approach to the tickets is indicated. The first step is to draw up the
> requirements for such a system and the following are proposed as a start
> to the discussion:
>
> 1. No information is explicitly passed to the hooks libraries during
> their initialization. Instead, they are able to access parameter
> information by reading the configuration.
>
> 2. Rather than include library-specific parameters as part of the
> "hooks-libraries" element, a separate "hooks-parameters" map is
> included. This holds parameters for all libraries, it being up to the
> library author to adopt a naming scheme to minimise clashes, e.g.
>
> "Dhcp4": {
> :
> "hooks-libraries": [
> "/opt/charging.so", "/opt/local/notification.so"
> ],
> "hooks-parameters": {
> "charging-alpha": "beta",
> "charging-foo": "bar",
> "notification-param", "value"
> }
> :
> }
>
> (The above example prefixes parameter names with the name of the
> library, but any scheme could be used.) True, there is the possibility
> of a name clash between libraries, but realistically that chance is
> small if some form of prefix scheme is used in naming.
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", "paramter-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.
> 3. It should be possible for hooks libraries to determine the component
> of Kea in which they are running. To explain this, at the top level,
> the Kea configuration file is a JSON map of the form:
>
> {
> "Dhcp4": {...},
> "Dhcp6": {...},
> "DhcpDdns": {...}.
> "Logging": {...}
> }
>
> It is feasible that a general-purpose library might be written that
> could be included into more than one component. In that case, it needs
> to know the component in which the configuration for that particular
> instance is included.
>
> 4. The configuration access interface should allow access to data
> through a simple naming scheme, e.g.
>
> Dhcp4/hooks-libraries[0] = "/opt/charging.so"
> Dhcp4/hooks-parameters/charging-alpha = "beta"
>
> (BIND 10 used slashes to separate components, but we can choose another
> separator.)
>
> 5. The configuration interface should:
> a. Allow counts of elements in lists and maps to be returned.
> b. Allow iteration over the elements of a list and a map.
>
> 6. Depending how sophisticated we want to get, the interface should
> allow sub-trees of the configuration to be passed around. For example,
> accessing "Dhcp4/hooks-parameters" should return a subtree representing
> the map of parameters. With this as the data on which the parser
> operates, accessing "charging-foo" (rather than
> Dhcp4/hooks-parameters/charging-foo) should return the value "bar".
>
> Thoughts?
>
> Stephen
>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 3
Date: Wed, 2 Sep 2015 12:00:15 +0100
From: Stephen Morris <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Hooks libraries and configuration information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 18, Issue 1
**************************************
