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

[Marcin Siodelski]

On 25.06.2015 15:49, 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 provided some thoughts about concurrency between the lease expiration
and the main thread, but since this is quite a complex topic and we will
have to explore this area some more, I put an explicit note that there
are no requirements for concurrency for 1.0. I left some more detailed
explanations in the preliminary design document. I can extend those with
the thoughts about impact on hooks in the concurrent model.

I imagine that some hooks would be stateless and would not bother that
two of the functions are ran at the same time. But, I can also imagine
that for some hooks that might be a problem, if the two functions access
the same data. If we ever try to do this concurrently, we can probably
add a configuration switch to signal whether the hook is thread-safe or
thread-unsafe and use multi threading or not.


>> 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'd leave it as is. Out of those three approaches, only second one
really makes a lot of sense. The other two are either less important or
not doable. For the server startup, you're usually not ready to perform
lease expiration when you load the leases because the whole server
infrastructure is not configured yet: D2 config not processed, some
hooks libraries not loaded. In order to reliably execute the lease
expiration process your server should technically be UP (and respond to
queries). So, this falls into your second approach. The third case is
when the server shuts down. Hm, so when it shuts down leases are no
longer renewed because the server doesn't process new queries and all
existing leases gradually expire. So, reclaiming leases right before the
shut down, while technically possible, doesn't bring a lot of benefit.

Thus, most of the use cases are during the run time anyway and I don't
think that such clarification is needed.

> 
> 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.
> 
> With the CommandMgr and control socket for statistics implemented,
> adding new commands is quite easy.
> 

I added the requirement but without the "command" as it narrows down the
possible approaches. It belongs to the design mostly.

> 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:
> 

I think both serve the informational role to the administrator and they
are usually used together. For example: I observe strange figures in my
statistics, I look into the logs for details. This is sort of like
different log severity levels...

> L4 MUST decrease subnet[id].assigned-addresses statistic when reclaiming
> an expired lease.
> 

Thanks, I have added it.

> Finally, it's rather obvious, but not explicitly stated, that all
> requirements apply to both v4 and v6.
> 

Yes. This is legitimate comment. I have added two requirements to cover
them separately.

Marcin