[kea-dev] memfile / loading of expired leases on startup

Chaigneau, Nicolas nicolas.chaigneau at capgemini.com
Tue Oct 4 13:16:07 UTC 2016


> On 15.09.2016 17:09, Chaigneau, Nicolas wrote:
> > Hello,
> > 
> > 
> > 
> > Following ticket #4294 that you've fixed in 1.1.0-beta (thanks again!), there is another related issue I'd like to discuss.
> > 
> > Upon startup, leases (using memfile) are loaded from disk, even if they are expired.
> > So if Kea is shut down for maintenance for example, and restarted after all the leases are expired, they are loaded anyway. This entails that the reclaim mechanism will have to catch up, and depending on configuration this can take quite a long time.
> > 
> > This causes two issues:
> > - Until the reclaim mechanism has finally caught up, the statistics will not be accurate.
> > - And this is lots of unnecessary work for this mechanism (hence for Kea), that could be avoided.
> > 
> > Proposed evolution: upon startup, when loading leases from disk, check if a given lease is expired. If so... don't load it.
> > 
> > Well, it's probably slightly more complicated than that. With lease affinity, maybe something like:
> > 
> > If <lease expiry> + hold-reclaimed-time > now : then load this lease 
> > If not, then just ignore this lease.
> > 
> > 
> > 
> > Thoughts ?
> > 
> > 
> 
> Nicolas,
> 
> Once again, sorry for the delays in responding to your post. It's been busy time for us.


No worries at all.
I was just confused at not seeing anything on the list. Turns out it is just very low traffic when no dev is around.


> 
> There are different ways of looking at the issue you have raised. There are a couple of things that happen when a lease is expired and
> reclaimed: DDNS, hooks invocation, database updates and finally statistics. From what you're saying, it seems that in your use case you just want to "forget" the expired leases after temporary down time of the server. But, in a general case, people may want to take actions upon expired leases even after the temporary downtime of the server. What about the case when the server crashed for any reason and has been brought up back? The short interruption of the server shouldn't cause us to not clean up DNS, and/or execute hooks? Or it should? It may depend on the use case. Say... you've had a server running for a while and you shut it down for a day. Maybe after a day it doesn't make sense to perform lease expirations? Or it does?
> 
> We took a "safe" approach to not make any assumptions. We load whatever have been in the lease database prior to server shut down and let the server deal with this situation using lease expiration mechanisms. Now, I suppose we could maybe perform lease reclamation while leases are loaded from a file (and while the server is starting up) but that would rather delay the startup of your server because not only would you have to load leases from file but also reclaim them.


Thanks for the explanation, that makes sense. I can see now that my suggestion was naively simplistic :)

Delaying the server startup is not a good idea, I agree. It can already take quite some time if there are lots of leases to load.


> 
> On the other hand, maybe it is worth considering to add a configuration flag to disable reclamation of leases on startup when the specific use case doesn't need reclamation?


It would certainly be useful to me.
As you guessed, in my case I don't have anything (DNS or hooks) that I need to handle on lease reclamation.

Currently I have a patch to do just that (without the configurability), but ultimately I'd like to get rid of it (that's the last remaining patch I need now, with Kea 1.1.0) so I can deploy Kea "out of the box".

I'll open a ticket for the suggestion.



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.



More information about the kea-dev mailing list