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. Fwd: Fwd: Re: Statistics design proposal for 0.9.2
(Thomas Markwalder)
2. Re: Fwd: Fwd: Re: Statistics design proposal for 0.9.2
(Thomas Markwalder)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Apr 2015 12:50:48 -0400
From: Thomas Markwalder <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] Fwd: Fwd: Re: Statistics design proposal for 0.9.2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
-------- Forwarded Message --------
Subject: Fwd: Re: [kea-dev] Statistics design proposal for 0.9.2
Date: Thu, 16 Apr 2015 12:49:43 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected] <[email protected]>
-------- Forwarded Message --------
Subject: Re: [kea-dev] Statistics design proposal for 0.9.2
Date: Thu, 16 Apr 2015 12:25:13 -0400
From: Thomas Markwalder <[email protected]>
To: Tomek Mrugalski <[email protected]>
On 4/14/15 9:18 AM, Tomek Mrugalski wrote:
> Hi all,
> One of the features planned for 0.9.2 are statistics. Here is the
> proposed design: http://kea.isc.org/wiki/StatsDesign.
>
> This design is not the most advanced or fully featured. It's a
> compromise between what we could do and what actually can do in the
> limited timeframe of 0.9.2 release.
>
> The basic concept is that the statistics are currently simple, but they
> can evolve over future releases. Whatever evolution path we'll choose,
> the API should remain stable, if possible.
>
> Please review and comment.
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
Review Comments Statistics Design:
I do think it is wise to keep a concurrent solution in our thinking. At
least, we should be
careful not to do anything that would preclude it from being done in the
future.
Marcin hit a point that I'm not sure has been addressed. What should
StatsMgr do upon a
reconfiguration? Dependent on what has changed a fair amount of any
existing statistics might
be obsolete. Personally, I think it would be acceptable to flush the
statistics upon reconfiguration.
At least for 0.9.2.
----------------------------------------------------------------------
Regarding Control Commands:
Since this is paving the way for the remote API ( I agree with this BTW),
I think we should alter the command structure so that we have both symmetry
between Stats API and the future remote command API, as well as
extensibility.
I propose the following structure for command requests:
{
"command": "cmd-value",
"args" : { "arg1" : "val1", "arg2" : 777, "arg3" : ....}
}
This makes the command arguments (or "parameters" if you prefer), a
named map
which the JSON parsing code will return as a distinct ElementPointer
containing
only the arguments. In other words, the arguments are segregated into a
single
container which can be passed around, free of any other than fellow
arguments.
This eliminates any code that needs the arguments from having to know the
first element (the command) is something that needs to be skipped or
ignored.
It also allows their content to be arbitrarily complex yet shields outer
level
processing. Note, their presence can still be optional for commands
that have
no required arguments.
We may also come to find that "commands" have other values common to
command
execution such as "priority" or "user-id". In other words values that
have to
do with performing a command in general, not arguments used by a specific
command. For example we might some day want something like this:
{
"command": "some-command",
"user-id" " "tmark",
"priority" : 99,
"args" : { "arg1" : "val1", "arg2" : 777, "arg3" : ....}
}
By structuring it as "command" and "args" now, we have room to flex in
the future.
----------------------------------------------------------------------
Regarding the Observation class:
It occurs to me that this class is very similar to ValueStorage template
class in libdhcprsv. The primary difference is that rather than storing
name-value pairs as ValueStorage does, these would store timestamp-value
pairs.
With the current design it would be possible for a developer to mistakenly
add a duration or a double to a statistic intended to be an integer counter.
There's no explicit way to say this statistic is of a one data type or
another.
The class also seems to be missing attributes for retaining maximum samples
or sample age, values set by setStorage() methods.
The name setStorage() is something of a misnomer. The name sounds like
it would
set everything to zero or something. In fact, rather than overload it,
I think it would
be clearer to have two distinct methods: setMaxSampleCount() and
setMaxSampleAge().
These two limits do not have to be mutually exclusive and using the same
method
name for both implies that the class enforces one limit or the other.
----------------------------------------------------------------------
Regarding Context class:
Context:
Since Context is intended to implement the hierarchy:
"Subnet[0].pool[1].assigned_addresses"
it would need data member(s) which uniquely identify it such as "group" or
"group_type" (for "subnet", "pool"...) and then an identifier within
the group,
to store the subnet_id or interface name. From a DBA view if you prefer,
Contexts have no place to store their primary key.
Also Context should have a reflexive relationship to model the fact that
"A Context may 0 or more Contexts"
Whether or not we implement hierarchical aspects in 0.9.2 or not, the
design
should account for it now.
As an aside, I would disagree with your description of Context as being
invisible to the user and more of a performance optimization. I think
it is
useful to discuss statistics in terms of "contexts" within the user
space.
Users would grasp this notion fairly well. As to their being a
performance
optimization, this could be true or false. What is true is that they
model/implement the statistics hierarchy.
----------------------------------------------------------------------
Context and Observation ought to have toJSON (and possibly fromJSON)
methods. Each class is responsible for invoking that method on all its
constituents. That way, extracting any portion of the statistics is a
matter
of selecting your beginning point in the hierarchy and invoking its
toJSON()
method.
----------------------------------------------------------------------
Maybe you could tone down the colour on your diagram. That yellow is REALLY
loud on the eyeballs. ;)
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20150416/f1aaafb8/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 16 Apr 2015 12:57:05 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Fwd: Fwd: Re: Statistics design proposal for
0.9.2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 4/16/15 12:50 PM, Thomas Markwalder wrote:
>
> ----------------------------------------------------------------------
> Regarding the Observation class:
>
> It occurs to me that this class is very similar to ValueStorage template
> class in libdhcprsv. The primary difference is that rather than storing
> name-value pairs as ValueStorage does, these would store timestamp-value
> pairs.
>
> With the current design it would be possible for a developer to mistakenly
> add a duration or a double to a statistic intended to be an integer counter.
> There's no explicit way to say this statistic is of a one data type or
> another.
>
> The class also seems to be missing attributes for retaining maximum samples
> or sample age, values set by setStorage() methods.
>
> The name setStorage() is something of a misnomer. The name sounds like
> it would
> set everything to zero or something. In fact, rather than overload it,
> I think it would
> be clearer to have two distinct methods: setMaxSampleCount() and
> setMaxSampleAge().
> These two limits do not have to be mutually exclusive and using the same
> method
> name for both implies that the class enforces one limit or the other.
>
I forgot to include that the parallel here does not stop with
ValueStorage<> but extends
to the dhcpsrv ParserContext class and how it utilizes the
ValueStorage<> class.
Thomas
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 13, Issue 10
***************************************
