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. Re: Suggestion for new hooks: server startup, shutdown,
reload (Tomek Mrugalski)
2. Re: Another hook suggestion: configurable periodic timers
(Tomek Mrugalski)
3. Re: Suggestion for new hooks: server startup, shutdown,
reload (Chaigneau, Nicolas)
4. Re: Another hook suggestion: configurable periodic timers
(Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 01 Dec 2014 16:57:11 +0100
From: Tomek Mrugalski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Suggestion for new hooks: server startup,
shutdown, reload
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 19.11.2014 17:04, Chaigneau, Nicolas wrote:
> I think it could be extended with new hook points. What do you think of the
> following proposal ?
>
> - "server startup" hook:
> Triggered after server has been started, configuration read, subnets
> initialized, leases loaded from backend; and just before the server actually
> starts processing DHCP packets.
> This would allow a hook library to:
> - Read its configuration (if it has one)
> - Perform the initialization steps it requires
> - If something wrong happens it could report through an output error code,
> which would cause the server to stop (as when the main configuration is
> incorrect, for instance).
>
> The hook should provide access to anything the hook library needs.
> For my needs, I can think of the subnets collection and the leases
> collection. The list is open though.
>
> - "server shutdown" hook:
> Triggered just before the server is about to be shut down.
> This would give a hook library a chance to perform some termination steps, if
> need be. Close handles, etc.
> (although on Linux it's not strictly needed, it's still cleaner to do so).
Both are useful, if you haven't done so, please submit a ticket and
describe your proposal. (Apologies if you already did that. I just
returned from 2 weeks vacation and I'm not entirely up to speed). We'll
process it the usual way - review on a team call on Wednesday and assign
it to a milestone.
> - "library reload" hook:
> Triggered after the hook library is reloaded (after the server has processed
> the "libreload" command)
> I think the same possibilities as in "server startup" should be provided.
Does it make sense? For a library, the libreload should be
indistinguishable from server shutdown and startup events, i.e. a
library is unloaded and later loaded again. So I don't see any useful
way to trigger such hook. If you need to know whether the library is
loaded upon startup or as a result of libreload, we could possibly add
an argument to load() that would signal that.
So, do you really need this? If yes, would an argument passed to load do
the trick?
Tomek
------------------------------
Message: 2
Date: Mon, 01 Dec 2014 17:21:24 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Another hook suggestion: configurable periodic
timers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 19.11.2014 17:50, Chaigneau, Nicolas wrote:
> I think of the following:
>
> Allow to define in configuration a list of timers, each of which would be
> composed of a period and identifier.
> For instance, with a timer of 5 min and one of 1H:
>
> "periodic-timers": [
> {
> "id": "timer-monitor"
> "period": 300,
> },
> {
> "id": "timer-1H"
> "period": 3600,
> }
> ]
>
> Kea would trigger a new hook "periodic timer" each time the period of one of
> the timers is reached.
> The hook library would receive both "id" and "period" arguments, which would
> allow to decide what to do (or do nothing).
There are two aspects of this proposal. First, Kea does not support
timers per se. At least not yet. This is something we will definitely
implement in the near future. One specific reason for timers support is
periodic lease clean up and expiration. We'll need a (configurable)
timer that will trigger 2 things: expired lease processing and lease
file rewrite. (or maybe there will be two separate timers for that, it
isn't designed yet). There's no question about it and it will be
implemented. I plan to file a ticket for that in the next couple days,
along with other tickets required for lease expiration/clean up.
The second aspect is whether to add custom (user definable) timers and a
hook they would trigger. I see some value in such capability, but its
implementation would take some time and honestly speaking there are more
urgent missing features. So feel free to submit a ticket for this, but
I'm afraid it is unlikely anyone would implement this anytime soon.
Tomek
------------------------------
Message: 3
Date: Mon, 1 Dec 2014 16:35:26 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Suggestion for new hooks: server startup,
shutdown, reload
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8417dd8...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello Tomek and welcome back :)
After posting this I realized that the server already offered "load" and
"unload" functions, which are sufficient for my needs.
I don't really need to distinguish these from the "start" / "shutdown" cases.
What could definitively be useful would be to add to the "load" function the
capacity to access Kea's configuration (in read-only mode).
For now I have to re-parse the configuration file myself.
... which works, even if it's not ideal, so... this is not a high priority
issue.
It would be nice to have this at some point in the future, though.
Regards,
Nicolas.
> -----Message d'origine-----
> De : Tomek Mrugalski [mailto:[email protected]]
> Envoy? : lundi 1 d?cembre 2014 16:57
> ? : Chaigneau, Nicolas; [email protected]
> Objet : Re: [kea-dev] Suggestion for new hooks: server startup, shutdown,
> reload
>
> On 19.11.2014 17:04, Chaigneau, Nicolas wrote:
> > I think it could be extended with new hook points. What do you think of the
> > following proposal ?
> >
> > - "server startup" hook:
> > Triggered after server has been started, configuration read, subnets
> > initialized, leases loaded from backend; and just before the server
> > actually starts processing DHCP packets.
> > This would allow a hook library to:
> > - Read its configuration (if it has one)
> > - Perform the initialization steps it requires
> > - If something wrong happens it could report through an output error code,
> > which would cause the server to stop (as when the main configuration is
> > incorrect, for instance).
> >
> > The hook should provide access to anything the hook library needs.
> > For my needs, I can think of the subnets collection and the leases
> > collection. The list is open though.
> >
> > - "server shutdown" hook:
> > Triggered just before the server is about to be shut down.
> > This would give a hook library a chance to perform some termination steps,
> > if need be. Close handles, etc.
> > (although on Linux it's not strictly needed, it's still cleaner to do so).
> Both are useful, if you haven't done so, please submit a ticket and describe
> your proposal. (Apologies if you already did that. I just returned from 2
> weeks vacation and I'm not entirely up to speed). We'll process it the usual
> way - review on a team call on Wednesday and assign it to a milestone.
>
> > - "library reload" hook:
> > Triggered after the hook library is reloaded (after the server has
> > processed the "libreload" command) I think the same possibilities as in
> > "server startup" should be provided.
> Does it make sense? For a library, the libreload should be indistinguishable
> from server shutdown and startup events, i.e. a library is unloaded and later
> loaded again. So I don't see any useful way to trigger such hook. If you need
> to know whether the library is loaded upon startup or as a result of
> libreload, we could possibly add an argument to load() that would signal that.
>
> So, do you really need this? If yes, would an argument passed to load do the
> trick?
>
> Tomek
>
>
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Message: 4
Date: Mon, 1 Dec 2014 16:42:31 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Another hook suggestion: configurable periodic
timers
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8417dd8...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello again,
I understand perfectly about priorities, no worries.
I'm just listing nice things that I could use if they happened at some point. :)
The hacky workaround will do, though.
Regards,
Nicolas.
> On 19.11.2014 17:50, Chaigneau, Nicolas wrote:
> > I think of the following:
> >
> > Allow to define in configuration a list of timers, each of which would be
> > composed of a period and identifier.
> > For instance, with a timer of 5 min and one of 1H:
> >
> > "periodic-timers": [
> > {
> > "id": "timer-monitor"
> > "period": 300,
> > },
> > {
> > "id": "timer-1H"
> > "period": 3600,
> > }
> > ]
> >
> > Kea would trigger a new hook "periodic timer" each time the period of one
> > of the timers is reached.
> > The hook library would receive both "id" and "period" arguments, which
> > would allow to decide what to do (or do nothing).
> There are two aspects of this proposal. First, Kea does not support timers
> per se. At least not yet. This is something we will definitely implement in
> the near future. One specific reason for timers support is periodic lease
> clean up and expiration. We'll need a (configurable) timer that will trigger
> 2 things: expired lease processing and lease file rewrite. (or maybe there
> will be two separate timers for that, it isn't designed yet). There's no
> question about it and it will be implemented. I plan to file a ticket for
> that in the next couple days, along with other tickets required for lease
> expiration/clean up.
>
> The second aspect is whether to add custom (user definable) timers and a hook
> they would trigger. I see some value in such capability, but its
> implementation would take some time and honestly speaking there are more
> urgent missing features. So feel free to submit a ticket for this, but I'm
> afraid it is unlikely anyone would implement this anytime soon.
>
> Tomek
>
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 9, Issue 1
*************************************
