[kea-dev] Call for comments about Lease Expiration requirements in Kea

[Thomas Markwalder]

On 6/25/15 9:49 AM, Tomek Mrugalski wrote:
> On 24/06/15 14:27, Marcin Siodelski wrote:
>> As a part of the preparation for the Kea 1.0, I would like to ask the
>> list participants to review and comment on a document presenting the
>> requirements for the "Lease Expiration", which is available here:
>>
>> http://kea.isc.org/wiki/LeaseExpirationRequirements
> That's a good proposal. Thanks for doing this. I have couple comments:
>
>> G1.MUST execute lease-expiration hook for each reclaimed lease
> Do we want to be more specific here that the hook will be called in the
> same hook library instance (i.e. the same process/thread) as all the
> other hooks? It may be easier for us to create a separate process/thread
> that does lease recycling in the background, but it would be much more
> difficult for hook lib developers as one of the callouts would be called
> in a separate process/thread. On the other hand, if we specify this up
> front in the requirements, it may limit the available designs for the
> expiration framework. Hmmm, so maybe not saying anything at all here and
> keep the text as is would be best?
>
I would not stipulate this as a requirement.  As you point out, this would
bind us to a specific solution. Requirements must not dictate design or
implementation details.  I could see adding it as a design consideration
in a preamble of the design document. 

>> C1. MUST provide a configuration switch to disable lease expiration. 
>> It MAY be combined with the switch controlling the period between
>> two consecutive processing cycles
> I would reword it to "... to disable lease expiration during run-time".
> I can imagine that, depending on your scenario, one of 3 approaches may
> be desired: 1. expire leases once on start-up; 2. expire leases
> periodically; 3. expire leases on shutdown. Case 1 is useful when you're
> recovering from a blackout or other misfortune. Case 2 is the normal
> operation that I expect to be used almost all the time. Case 3 is useful
> when you want to squeeze top performance from your server, but still
> want to have a clean database/dns afterwards.
>
> I think you should also add two extra requirements. The first one
> probably belong to a new administrative section:
> A.1 There MUST be a command to manually trigger lease reclaimation.
I would reword this to "There MUST be a means to manually trigger lease
reclamation"

> With the CommandMgr and control socket for statistics implemented,
> adding new commands is quite easy.
>
> Another comment is about statistics. Not sure if logging and statistics
> should be treated together (they are both used for debugging or general
> awareness of what's happening in the system) or separately (logs and
> statistics are handled in very different ways). In any case, here's one
> entry that should be added:
>
> L4 MUST decrease subnet[id].assigned-addresses statistic when reclaiming
> an expired lease.
>
> Finally, it's rather obvious, but not explicitly stated, that all
> requirements apply to both v4 and v6.
Obvious but should be stated.  Good catch.

> Tomek
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev