[kea-dev] Lease File Cleanup in Kea - Design Document

[Chaigneau, Nicolas]

Hello Marcin,


Thanks for sharing this design document.
You'll find my comments hereafter.

Regards,
Nicolas.




1) about the clean-up algorithm

> The cleanup of any file by the kea-lfc is achieved by removing lease entries which have expired, i.e. "expired" field holds the time later than the current time minus an arbitrary value to account for a possible positive time skew.


>From what I understand of this, the LFC will simply keep lines for which the "expired" field is not reached yet (and remove the others), regardless of the lease actual status.
This implies that:
- If for a given lease, a DHCP Release has been processed, only the related entry in the file is cleaned up. Other entries (related to the initial request, and renew - if any) associated to this given lease are maintained until they also expire, even though there is no such lease anymore.
- If a client sends renews, they will all be kept until they individually expire. For a typical renew-timer set to half of lease duration, this means that for an active lease there will be two entries in the lease file. Also, faulty devices may send many renews, in which case we would have as many non expired entries for the same lease.

Is that correct ?

>From the requirements page, I understood that all redundant entries would be removed.
To achieve this I believe you would need to keep in memory the list (maybe as a hash ?) of active leases along with their expiration time, which you would update while parsing <previous lease file> and <lease file copy>. Only when the parsing is complete could <LFC output file> be created.

This would also address the issue you noted in the case of a crash between renaming <LFC output file> and deleting <lease file copy>.

That said, I'm not sure this is really indispensable. The proposed algorithm ensures that all redundant information will eventually be cleaned up. This may take a while though, depending on the configured lease time. In my case I plan to have a relatively short lease time so that would probably not be too much of an issue.

If it's too complicated to handle, maybe this could be implemented in an ulterior version of LFC ?

(would that be complicated ? I guess Kea will have to read the two files anyway so it can populate its lease backend. Maybe this is reusable for kea-lfc ?)




2) about kea-lfc usage

> kea-lfc [-4|-6] -p <previous-lease-file-name> -i <lfc-input-lease-file-name> -o <output-file-name> -c <kea-configuration-file>

The example allows to specify the three file names.
However according to "how the name is constructed", I believe these are not necessary, since they are automatically constructed by Kea (from the actual lease file name).
Moreso, it is required for "output" and "previous" files to be on the same filesystem (otherwise the rename would be a copy).

Consequently, only <kea-configuration-file> seems necessary to me. It allows to get the actual lease file name, and derive the name of the related lease files.





> Hi,
> 
> Following the thread regarding the requirements for Lease File Cleanup in Kea (https://lists.isc.org/pipermail/kea-dev/2014-December/000211.html), I have created a short design document for this feature:
> 
> http://kea.isc.org/wiki/LFCDesign
> 
> I have to admit that I was in rush preparing the document, so please forgive me if anything is underspecified or unclear. I will be happy to clarify if you point out the specific paragraphs that should be made clearer.
> 
> The last section of this document proposes the split of implementation into actual tickets. It goes along with the initial estimates for the implementation work (specified in days).
> 
> Please review as soon as possible because we need to incorporate this in our release schedule this week.
> 
> Thanks,
> Marcin
> 


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.