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: On persistent lease file clean-up mechanism
(Marcin Siodelski)
2. Re: Another hook suggestion: configurable periodic timers
(Marcin Siodelski)
3. Re: Suggestion for new hooks: server startup, shutdown,
reload (Marcin Siodelski)
4. Re: On persistent lease file clean-up mechanism
(Chaigneau, Nicolas)
5. Re: Pool usage monitoring in Kea ? (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Nov 2014 16:38:25 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] On persistent lease file clean-up mechanism
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Nicolas,
Thanks for the write-up. In general, I feel it is a right direction. But
I also agree it is not a trivial matter as the solution should not
impair the DHCP service while the clean-up is in place. Also, the
solution should prevent race conditions and data loss.
As a result of the discussions on the mail list we will have to create a
page on the trac wiki which will contain requirements for this feature
as well as some little design. I will make sure such page is created
once we have first thoughts exchanged.
We haven't yet gone through the phase of discussing this feature because
it was somewhat out of scope for the 0.9.1 release. So, all my thoughts
here are preliminary and I may be wrong.
I think we should consider other triggers for the clean-up apart from
the timer. Though, the timer could be the first one to implement and
other could wait. We could consider triggering clean-up when the lease
expiration counter is X, or number of renewed leases is Y etc.
I agree that the clean-up should be performed on a renamed file and the
server should use a different/empty file for new lease updates while the
clean-up is in place. However, there is a question how the data is
combined when the clean-up is done. Keeping the compressed (cleaned-up)
file separately from the currently used file is an option, but it means
that each clean-up operation results in creation of one new file holding
partial information about the leases. I believe that in many cases
administrators would rather want lease information be stored in a single
file, not multiple. Also, the subsequent clean-up operations would need
to process all saved lease files, since each of them potentially holds
some lease information which may have expired.
I tend to think that the lease data aggregation should rather take place
at the end of the clean-up phase and should result in having at most two
files: one currently used by the server to write lease updates until the
next clean-up is triggered. Another one, holding all remaining
(historical) and cleaned-up lease information. Ideally, they should be
combined into a single file, but appending the contents of the currently
used file may have some impact on the service availability for a period
of time when the append is being done.
So, the option 1 would be...
When the clean-up is triggered, the lease file used currently by the
server is renamed. The new file is created for the server to use. The
renamed file contents are appended to the lease file holding historical
data. Then, clean-up is performed on this file with appended
information. The server keeps using the same lease file (other than the
one on which the clean-up was performed) until next clean-up comes.
And option 2 ...
There is only one lease file. When the clean-up is triggered this file
is renamed and the new file is created for the server to write new lease
updates. When the clean-up is completed on the renamed lease file, the
DHCP service is ceased for a short period of time when the most recent
lease updates (gathered during clean-up) are appended to the cleaned-up
file and the server switches to use this file.
Both solutions are similar, but second option results in use of a single
lease file (which I personally prefer). The first option has an
advantage that there is no need to copy over the most recent information
to the single lease file.
I am not sure I fully understand the proposal of keeping the clean-up
interval "at least equal to maximum lease time value". Are you proposing
that clean-ups are triggered no more frequently than maximum
valid-lifetime that may occur for any lease in a lease file? Why server
restart is associated with the lease file cleanup in this context? The
clean-up should not be triggered until the server starts up and loads
lease information from the existing lease files, at which point the
server records all updates to leases in an available lease file. And the
clean-up should ensure that the server always has a lease file to write to.
Marcin
On 11/19/14 15:27, Chaigneau, Nicolas wrote:
> 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.
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 2
Date: Mon, 24 Nov 2014 17:59:26 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Another hook suggestion: configurable periodic
timers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Nicolas,
Can you please describe some of the use cases you have in mind here?
Typically, hooks require access to the contextual data. For example, a
pkt4_receive hook requires pkt4 object be passed to it by the server.
Depending on the purpose, the "timer hook" could also require access to
some data contexts (e.g. a hook which offers periodic statistics
gathering needs to access some statistical data counters) but the type
of the contextual data can't be known upfront when implementing a hook
and this seems to limit the usability of such a hooks to only those
situations when the context is not needed or when the library maintains
its own context. Then, when the library is unloaded the context is lost.
If the "timer hook" is meant to just perform some periodic operations
which don't depend on any data contexts it is worth to consider whether
the same can be achieved with a cron job?
I don't want it to sound that I am not opposed to this idea. I try to
understand the use cases so as we rather provide some generic mechanism,
rather than something of a limited usability.
Marcin
On 11/19/14 17:50, Chaigneau, Nicolas wrote:
> 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
>
------------------------------
Message: 3
Date: Mon, 24 Nov 2014 18:09:25 +0100
From: Marcin Siodelski <[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
Nicolas,
At present, hook libraries have no means to access the configuration
manager or the lease database. However, we plan to implement it. Please
see: http://kea.isc.org/ticket/3456 and some other tickets it references.
Marcin
On 11/20/14 16:37, Chaigneau, Nicolas wrote:
>
> Woops... I've just realized that there are already "load" and "unload"
> functions for hook libraries!
> My bad.
>
>
> Still, I've got some questions:
>
> I'm not sure what can be done with the "LibraryHandle" argument ? (apart from
> registering and deregistering callouts)
>
> Would it possible in the "load" function to access the subnets, leases, etc,
> managed by the server ?
>
>
>
>
> Regards,
> Nicolas.
>
>
> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De
> la part de Chaigneau, Nicolas
> Envoy? : mercredi 19 novembre 2014 17:05
> ? : [email protected]
> Objet : [kea-dev] Suggestion for new hooks: server startup, shutdown, reload
>
> 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.
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 4
Date: Mon, 24 Nov 2014 17:20:42 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] On persistent lease file clean-up mechanism
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84143d9...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello Marcin,
Thanks for your feedback!
Both option 1 and 2 you describe have, in my opinion, one common issue: the
server must halt processing the DHCP packets in order to rewrite the lease
file, which can take some time when dealing with very large lease files.
The main point of the algorithm I proposed was to eliminate the file clean-up
entirely, while ensuring data integrity (no loss of data).
This is achieved through a time-triggered rotation of the lease file.
I'll take an example, hopefully making myself clearer :)
With a lease time of 30 minutes, and a rotation of the lease file triggered
every 30 min:
Server is started at t0.
At t0 + 1 min, lease L1 is allocated, and written in <lease file>.
At t0 + 29 min, lease L2 is allocated, and written in <lease file>.
At t0 + 30 min, the clean-up mechanism is triggered:
<lease file> is renamed to <old lease file> (which now contains leases L1 + L2).
<lease file> is recreated, empty.
At t0 + 31 min, lease L1 (not renewed) expires.
At t0 + 44 min (considering a renew-timer of 15 min), lease L2 is renewed.
At t0 + 60 min, the clean-up mechanism is triggered again:
<lease file> is renamed to <old lease file>. Previous <old lease file> is
simply overwritten.
It's alright because any lease that is not expired has necessarily been
renewed, hence is in <lease file>.
This property is verified as long as we ensure that the clean-up interval is at
least equal to the maximum lease time value.
At any time if the server is restarted, all non-expired leases can be retrieved
from the aggregation of <lease file> and <old lease file>.
Hence, no data loss, at the cost of a slightly more complicated start-up
processing.
This is a simple scenario where the lease file is cleaned-up only on a regular
time trigger.
I understand that combining this with other clean-up triggers, such as those
you describe, will make things much more complicated... possibly with multiple
lease files, and the need to decide when an older lease file can be safely
deleted. I really haven't given this much thought, I only wanted to propose
something that would be sufficient for my needs.
Anyway, thanks for reading and considering this :)
Regards,
Nicolas.
> Nicolas,
>
> Thanks for the write-up. In general, I feel it is a right direction. But I
> also agree it is not a trivial matter as the solution should not impair the
> DHCP service while the clean-up is in place. Also, the solution should
> prevent race conditions and data loss.
>
> As a result of the discussions on the mail list we will have to create a page
> on the trac wiki which will contain requirements for this feature as well as
> some little design. I will make sure such page is created once we have first
> thoughts exchanged.
>
> We haven't yet gone through the phase of discussing this feature because it
> was somewhat out of scope for the 0.9.1 release. So, all my thoughts here are
> preliminary and I may be wrong.
>
> I think we should consider other triggers for the clean-up apart from the
> timer. Though, the timer could be the first one to implement and other could
> wait. We could consider triggering clean-up when the lease expiration counter
> is X, or number of renewed leases is Y etc.
>
> I agree that the clean-up should be performed on a renamed file and the
> server should use a different/empty file for new lease updates while the
> clean-up is in place. However, there is a question how the data is combined
> when the clean-up is done. Keeping the compressed (cleaned-up) file
> separately from the currently used file is an option, but it means that each
> clean-up operation results in creation of one new file holding partial
> information about the leases. I believe that in many cases administrators
> would rather want lease information be stored in a single file, not multiple.
> Also, the subsequent clean-up operations would need to process all saved
> lease files, since each of them potentially holds some lease information
> which may have expired.
>
> I tend to think that the lease data aggregation should rather take place at
> the end of the clean-up phase and should result in having at most two
> files: one currently used by the server to write lease updates until the next
> clean-up is triggered. Another one, holding all remaining
> (historical) and cleaned-up lease information. Ideally, they should be
> combined into a single file, but appending the contents of the currently used
> file may have some impact on the service availability for a period of time
> when the append is being done.
>
> So, the option 1 would be...
> When the clean-up is triggered, the lease file used currently by the server
> is renamed. The new file is created for the server to use. The renamed file
> contents are appended to the lease file holding historical data. Then,
> clean-up is performed on this file with appended information. The server
> keeps using the same lease file (other than the one on which the clean-up was
> performed) until next clean-up comes.
>
> And option 2 ...
> There is only one lease file. When the clean-up is triggered this file is
> renamed and the new file is created for the server to write new lease
> updates. When the clean-up is completed on the renamed lease file, the DHCP
> service is ceased for a short period of time when the most recent lease
> updates (gathered during clean-up) are appended to the cleaned-up file and
> the server switches to use this file.
>
> Both solutions are similar, but second option results in use of a single
> lease file (which I personally prefer). The first option has an advantage
> that there is no need to copy over the most recent information to the single
> lease file.
>
> I am not sure I fully understand the proposal of keeping the clean-up
> interval "at least equal to maximum lease time value". Are you proposing that
> clean-ups are triggered no more frequently than maximum valid-lifetime that
> may occur for any lease in a lease file? Why server restart is associated
> with the lease file cleanup in this context? The clean-up should not be
> triggered until the server starts up and loads lease information from the
> existing lease files, at which point the server records all updates to leases
> in an available lease file. And the clean-up should ensure that the server
> always has a lease file to write to.
>
> Marcin
>
>
> On 11/19/14 15:27, Chaigneau, Nicolas wrote:
> > 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: 5
Date: Mon, 24 Nov 2014 18:26:57 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>, Tomek
Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Pool usage monitoring in Kea ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
The ticket http://kea.isc.org/ticket/3457 (currently in the 0.9.1.
release milestone) is about enabling access for the hook libraries to
the lease manager. This would allow for making queries to the lease
database (of any type) and perhaps collecting some statistical
information. Unfortunately, this is a future work. Plus, depending on
the type of the statistics, the lease information returned by the lease
manager's API may require some additional processing to get the desired
counters. But, this is usually unavoidable and doesn't cause much burden
as it operates on in-memory objects.
Marcin
On 11/21/14 10:36, Chaigneau, Nicolas wrote:
> Alright, so I've a solution for the missing part: how to retrieve the leases
> currently in use, within each defined subnet, upon server startup.
>
> In the hook library "load" function, grab the lease file and kea config file.
> Parse them, populate appropriate memory objects, and voila!
>
> But it's not terribly efficient: the lease file is parsed twice, first by
> Kea, then by the hook library.
>
> There should be a better way to do this...
>
>
>
> Regards,
> Nicolas.
>
>
> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De
> la part de Chaigneau, Nicolas
> Envoy? : mardi 18 novembre 2014 17:32
> ? : Tomek Mrugalski; [email protected]
> Objet : Re: [kea-dev] Pool usage monitoring in Kea ?
>
> Hello,
>
>
> Thanks for your input!
>
>
> I've looked into Kea hooks API, and built my very first (and very
> rudimentary) hook library to get a grasp of what can be done.
>
> So far with lease4_select, lease4_release (and lease4_expire in the future)
> I'm able to iterate on the pools to get the total number of leases associated
> to a subnet, keep track of the number of used leases, and report the subnet
> pools usage.
>
> One thing I don't know is how to get the number of leases loaded from the
> persistent lease file upon server startup.
> Could it be possible to add a hook for the event "lease loaded from
> persistent file" ? or provide another way to achieve this ?
>
> Another question: would it be complicated to add the possibility to get the
> number of allocated leases from the hooks arguments ?
> (mustn't the server know how many leases are free/occupied when trying to
> allocate a new one ? that's probably a stupid question, but I don't know how
> subnets/pools and leases objects are linked...)
>
>
> Your proposal of allowing to query the server for statistics is interesting.
>
> What I need is to be able to:
> 1) get the list of configured subnets (at least their id and text
> representation, eg: "10.156.0.0/15". Possibly also the associated relay addr).
> And, for each subnet: the total number of addresses in the pools, and the
> number of currently leased addresses.
> 2) get the number of each type of DHCP packet (Discover, Ack...) received and
> sent by the server during a given time interval (which would have to be
> configurable).
>
> Most of this can be achieved through the hooks API:
> 2) can easily be done with hooks "pkt4_receive" and "pkt4_send".
> 1) can partially be done with hooks "lease4_select", "lease4_release" and
> "lease4_expire".
>
> As you said it's a bit "hacky" though, and if there's a better way to do it,
> I'll take it :)
>
>
>
>
> Have a nice vacation !
>
> Regards,
> Nicolas.
>
>
>> On 14/11/14 03:43, Chaigneau, Nicolas wrote:
>>> I'm looking into the possibility to monitor the pools usage in Kea,
>>> more specifically for a "memfile" back-end. For dhcpd, we've been
>>> using an external tool: dhcpd-pools
>>> (http://dhcpd-pools.sourceforge.net/) which works by parsing dhcpd
>>> config and lease files. This tool is used at regular time intervals
>>> to produce reports in a log file.
>>>
>>> This could be ported to support Kea, but I wonder if there could be
>>> a better way ? For one thing, dhcpd-pools has to parse the lease
>>> file, and this is quite slow for very large lease files.
>> Possibly, yes. One thing to remember is that the lease file will contain
>> expired leases. They should not be counted as used as they are available for
>> the server assignment.
>>
>>> Would it be possible to use Kea hook API to provide this
>>> functionnality ? I've seen the "lease4_select" hook which seems
>>> interesting. Do you think the "subnet4collection" argument could be
>>> used to check how many leases are currently allocated for each pool,
>>> and report the information ?
>> You could implement your own statistics module using hooks. You'd create a
>> table of integers called subnets_counter and a size of subnet4collection
>> returned in subnet4_select for example. You'd need to manage that statistic
>> from two points. First, lease4_select callout would increase a given
>> statistic when new lease is assigned (just pay attention to fake_allocation
>> flag - the callout is called also during Discover processing and the lease
>> is not assigned then) or existing lease is released (see lease4_release
>> callout).
>>
>> That would give you very efficient statistics gathering mechanism. It would
>> be accurate as long as no leases are expired. Unfortunately, we don't have
>> the proper expiration mechanism yet. Once it is implemented, we'll likely
>> add extra callouts: lease4_expire and lease6_expire.
>>
>> However, this approach is a bit hacky. The proper solution for statistics
>> gathering will be more involved. In bind10 days, Kea had a control socket
>> that used to receive commands from bind10 framework. The commands and the
>> responses from the server were JSON structures. When we removed the bind10
>> framework, we lost the communication channel. Kea now has the capability to
>> process the commands, just there's no way to receive those commands or send
>> responses. This is something we plan to do in 0.9.1 release. It won't be
>> super-fancy - probably just a unix socket for now.
>>
>> Currently Kea supports 3 commands: shutdown, libreload, config-reload.
>> As a temporary workaround, we use signals to trigger those commands.
>>
>> It seems reasonable to extend that commands list with an additional command,
>> maybe 'stats-get'. If you are interested, please take a look at
>> ControlledDhcpv4Srv::processCommand in src/bin/dhcp4/ctrl_dhcp4_srv.cc.
>>
>> As for the actual stats gathering, the statistics code should work
>> uniformly for all backends. We would probably need to extend the
>> generic API to LeaseMgr (see src/lib/dhcpsrv/lease_mgr.h) with
>> something like
>> getStats() that would return an array with number of leases in each subnet
>> (or rather an array of structures, with each structure having least count
>> information. That way we could extra stats in the future without changing
>> the API).
>>
>> Once LeaseMgr API is extended, we'd need to implement for specific backends,
>> e.g. Memfile_LeaseMgr (see src/lib/dhcpsrv/memfile_lease_mgr.h).
>>
>> This is how I would do statistics. Please note that this is a napkin style
>> design. Just something Marcin and I discussed very briefly, without giving
>> it more thought. One thing to remember is that the number of statistics will
>> keep growing over time. For now, you only need lease number, but after that,
>> additional metrics will be requested, some of which can't be extracted from
>> the lease manager. For example - a number of total leases, number of
>> reserved hosts, number of reserved hosts that have active leases, number of
>> malformed packets received, number of packets that caused subnet selection
>> failures etc.
>>
>> I suppose that's all I can offer at this time. Statistics is something that
>> we definitely will want to implement. What would be very useful is if you
>> could think about what type of statistics you'd want. We won't be able to
>> implement them all immediately, but knowing what will be needed eventually,
>> will be helpful with the design decisions.
>>
>> Ok, this is my last mail to kea-dev for the next 2,5 weeks. IETF meeting is
>> wrapping up today and I'm going on vacation.
>>
>> Cheers,
>> 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
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 8, Issue 11
**************************************
