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: Requirements for the Logging and Diagnostics in Kea
(Tomek Mrugalski)
2. Re: Requirements for the Logging and Diagnostics in Kea
(Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Tue, 07 Apr 2015 21:00:34 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Requirements for the Logging and Diagnostics in
Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 07.04.2015 13:10, Marcin Siodelski wrote:
> Hi All,
>
> One of the goals for the Kea 0.9.2. release is "Logging and Diagnostics
> Improvements". This includes a number of little improvements and tweaks
> to the existing logging system, but some of the possible enhancements
> are much more significant than this.
>
> I have created the requirements document
> http://kea.isc.org/wiki/DiagnosticsRequirements for "Logging and
> Diagnostics Improvements", which is meant to summarize the requirements
> mentioned in different discussions we've had so far.
Thanks for writing this document. It's very good, but I do have a couple
small comments:
> 3. The tool MUST output lease information to the CSV file having the
> same format as the lease file created by the Memfile backend, but the
> order of columns MAY be different.
Why order of columns MAY be different? It would make any automation
impossible (or at least very difficult). Note that such a tool could
double as a migration tool between backends, but would be next to
useless if the order wasn't maintained.
It would be also difficult to automate any sanity checks or statistics
if the other is different.
> 9. and 14.
I would like to raise a point mentioned by Angelo couple days ago. It
would be very helpful to log the amount of time it took to execute the
callout. It's very likely that we'll also be exporting this info as one
of the statistics.
> 15.
Not sure if that's included in this requirement or not, but one user
strongly requested that the Kea code should log its decisions in a
format that contains at least the same amount of information as
ISC-DHCP. In particular, the following info was requested to be logged
in IPv4:
DHCPDISCOVER from <client hwaddr> via <giaddr>
DHCPOFFER on <lease ip addr> to <client hwaddr> via <giaddr>
DHCPREQUEST (<client state>) for <lease ip addr> from <client hwaddr>
via <giaddr>
DHCPACK on <lease ip addr> to <client hwaddr> via <giaddr>
DHCPNAK to <client hwaddr> via <giaddr>
DHCPDECLINE of <lease ip addr> from <client hwaddr> via <giaddr>
DHCPRELEASE of <lease ip addr> from <client hwaddr> via <giaddr>
DHCPINFORM from <client hwaddr> via <giaddr>
I suppose it can be extended with additional details, e.g. why NAK was
sent or the interface name the packet was received on.
> 16. Kea MUST log when the significant logical unit of work during the
> packet processing has ended.
I'm not opposing that, but a well defined definition of "significant
logical unit of work" must be written (and maintained). A list of all
steps would be an useful thing to have.
> 19, 20, 21
Additional information should be provided if possible. In particular,
the interface name and on which the packet was received, also relay
information if available. Those cases usually mean that there's some
troublemaking device in the network. Assisting an administrator in his
quest to find it would be useful.
There are two items 24.
There are two items I'd like to have on this list. One user requested to
have a list of
I would add another item to the list. Have an simple to configure
ability to log all messages to a single destination. In the BIND10 days,
we used to be able to specify loggers name as "*" and redirect
everything to a single destination. With bindctl long gone, that is no
longer possible, at least I failed to configure it. This is pretty
important in my opinion. Even the best logging messages are useless if
you happen to misconfigure your logging output and the messages are not
logged at all.
Tomek
------------------------------
Message: 2
Date: Wed, 08 Apr 2015 09:18:05 +0200
From: Marcin Siodelski <[email protected]>
To: Tomek Mrugalski <[email protected]>, [email protected]
Subject: Re: [kea-dev] Requirements for the Logging and Diagnostics in
Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 07.04.2015 21:00, Tomek Mrugalski wrote:
> On 07.04.2015 13:10, Marcin Siodelski wrote:
>> Hi All,
>>
>> One of the goals for the Kea 0.9.2. release is "Logging and Diagnostics
>> Improvements". This includes a number of little improvements and tweaks
>> to the existing logging system, but some of the possible enhancements
>> are much more significant than this.
>>
>> I have created the requirements document
>> http://kea.isc.org/wiki/DiagnosticsRequirements for "Logging and
>> Diagnostics Improvements", which is meant to summarize the requirements
>> mentioned in different discussions we've had so far.
> Thanks for writing this document. It's very good, but I do have a couple
> small comments:
>
Thanks!
>> 3. The tool MUST output lease information to the CSV file having the
>> same format as the lease file created by the Memfile backend, but the
>> order of columns MAY be different.
> Why order of columns MAY be different? It would make any automation
> impossible (or at least very difficult). Note that such a tool could
> double as a migration tool between backends, but would be next to
> useless if the order wasn't maintained.
>
> It would be also difficult to automate any sanity checks or statistics
> if the other is different.
>
So how about removing the statement about the ordering? While I take
your point about the possibility to use it as a migration tool this
document is about the requirements for diagnostics and this doesn't
require the strict ordering.
>
>> 9. and 14.
> I would like to raise a point mentioned by Angelo couple days ago. It
> would be very helpful to log the amount of time it took to execute the
> callout. It's very likely that we'll also be exporting this info as one
> of the statistics.
>
Agreed. I added the requirement for the hooks framework to log the
execution time for each (out of many) callouts.
>> 15.
> Not sure if that's included in this requirement or not, but one user
> strongly requested that the Kea code should log its decisions in a
> format that contains at least the same amount of information as
> ISC-DHCP. In particular, the following info was requested to be logged
> in IPv4:
>
> DHCPDISCOVER from <client hwaddr> via <giaddr>
> DHCPOFFER on <lease ip addr> to <client hwaddr> via <giaddr>
> DHCPREQUEST (<client state>) for <lease ip addr> from <client hwaddr>
> via <giaddr>
> DHCPACK on <lease ip addr> to <client hwaddr> via <giaddr>
> DHCPNAK to <client hwaddr> via <giaddr>
> DHCPDECLINE of <lease ip addr> from <client hwaddr> via <giaddr>
> DHCPRELEASE of <lease ip addr> from <client hwaddr> via <giaddr>
> DHCPINFORM from <client hwaddr> via <giaddr>
>
> I suppose it can be extended with additional details, e.g. why NAK was
> sent or the interface name the packet was received on.
>
I don't want to overspecify it in the requirements doc. I'd rather put
it into the design doc instead.
>> 16. Kea MUST log when the significant logical unit of work during the
>> packet processing has ended.
> I'm not opposing that, but a well defined definition of "significant
> logical unit of work" must be written (and maintained). A list of all
> steps would be an useful thing to have.
>
Sigh. Maybe. But it is hard to do it upfront without missing something
important. I think it may be better to go over the code, update it as
appropriate and then think whether it may be categorized.
>> 19, 20, 21
> Additional information should be provided if possible. In particular,
> the interface name and on which the packet was received, also relay
> information if available. Those cases usually mean that there's some
> troublemaking device in the network. Assisting an administrator in his
> quest to find it would be useful.
>
I added a separate requirement for this.
> There are two items 24.
>
Renumbered.
> There are two items I'd like to have on this list. One user requested to
> have a list of
>
> I would add another item to the list. Have an simple to configure
> ability to log all messages to a single destination. In the BIND10 days,
> we used to be able to specify loggers name as "*" and redirect
> everything to a single destination. With bindctl long gone, that is no
> longer possible, at least I failed to configure it. This is pretty
> important in my opinion. Even the best logging messages are useless if
> you happen to misconfigure your logging output and the messages are not
> logged at all.
>
I added a requirement for the single common logging entry for all
loggers. But, this is only one item. You mentioned two?
Marcin
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 13, Issue 3
**************************************
