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. On persistent lease file clean-up mechanism (Chaigneau, Nicolas)
2. Suggestion for new hooks: server startup, shutdown, reload
(Chaigneau, Nicolas)
3. Another hook suggestion: configurable periodic timers
(Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Wed, 19 Nov 2014 14:27:35 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] On persistent lease file clean-up mechanism
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84143ce...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I'd like to discuss the topic of cleaning-up the lease file in the case of a
"memfile" back-end.
That's probably something you've already thought of, but I didn't find specific
implementation discussed of on the mailing list archive.
Since it's still yet to be implemented, I'd like to share my 2 cents on the
subject.
This is not a trivial matter: in the context of high availability and very
large lease files involved, the situation of a server being unresponsive for
several seconds while it handles rewriting the lease file is not something we
can afford.
So here's how I would do it:
- define a lease file clean-up interval; for instance 1H.
- every 1H, trigger the clean-up mechanism:
- rename <lease file> to <old lease file> (<lease file>~ or any other
naming convention)
- recreate an empty <lease file>
- close and reopen Kea's file handle on <lease file>
- at server startup, load in memory both <lease file> and <old lease file>
(aggregating their content)
If we ensure that the clean-up interval value is *at least* equal to the
maximum lease time value, this guarantee no data can be lost during a server
restart: any lease not expired is necessarily either in the current or old
lease file (possibly both).
Both <lease file> and <old lease file> being in the same directory, hence on
the same filesystem, the rename operation is immediate. The file's inode and
content are unchanged. Only the file name is modified.
This probably would not be suitable for everyone's needs, so maybe this could
be an optional mechanism.
What do you think ?
Regards,
Nicolas.
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: 2
Date: Wed, 19 Nov 2014 16:04:56 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Suggestion for new hooks: server startup, shutdown,
reload
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84143ce...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello again,
The hook mechanism provided within Kea looks very handy.
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).
- "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.
Regards,
Nicolas.
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: 3
Date: Wed, 19 Nov 2014 16:50:41 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Another hook suggestion: configurable periodic
timers
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84143ce...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello again,
Another need I have is to perform periodic actions within a hook library.
A hacky way to do so is, for instance, on a trigger "pkt4_receive":
Check if it's time to perform the periodic action, then rearm the timer
afterwards (ie, set the future timestamp at which the action should be handled
again).
The drawback is that it depends on traffic being sent to the server. And it's
not a terribly clean way to handle this...
(Still, it works. So the following proposal is not of high priority or
anything; I'm just opening the discussion.)
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).
(apologies for overloading the mailing list; this will be my last one for
today, I promise !)
Regards,
Nicolas.
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 8, Issue 9
*************************************
