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

Marcin Siodelski marcin at isc.org
Mon Jan 26 15:05:49 UTC 2015


Nicolas,

Ok, this is actually a good point. The pid file location or at least its
name should be configurable in runtime.

So, with regards to the previous email you sent today. Is your use case
to run multiple instances of the DHCP server or one instance listening
on multiple interfaces/addresses. Or both?

Marcin


On 01/26/15 15:34, Chaigneau, Nicolas wrote:
>
> Hello Marcin,
>
>
> A point which I forgot to address, regarding the "concurrent runs" issue:
>
> "The kea-lfc implements locking using the PID file to prevent
> concurrent runs. When the kea-lfc is started, it checks for the
> presence of the PID file. If the file exists, it checks if the process
> with a PID from the PID file is running. If the process is running,
> the application terminates. If the PID file doesn't exist or the
> process with a given PID is not running, the kea-lfc creates a new PID
> file with its own PID and continues to run."
>
>
> Several kea servers may run on a single host, each having its own
> separate configuration.
> Consequently, kea-lfc must also be allowed to run concurrently (one
> instance of kea-lfc matching each instance of kea).
> To allow this, the PID file should be configurable. I think the
> logical place would be in kea's configuration file.
>
>
>
> Regards,
> Nicolas.
>
>
> > All,
> >
> > I have updated the Lease File Cleanup design with the comments from
> Stephen and Tomek (see ticket #3685). You may want to have a look and
> see if there is anything glaring. Minor comments like: spelling
> errors, some naming conventions may also be useful but they have
> little chance of being applied by the 0.9.1 release.
> >
> > The major change (which was actually applied in the LFC requirements
> > document): http://kea.isc.org/wiki/LeaseFileCompressionRequirements
> is the removal of the following requirement:
> >
> > "b. The LFC should not remove the contents of the lease file which
> is not identified as a lease information or is an invalid lease
> information."
> >
> > Although, I initially thought it would be a useful capability, I now
> tend to think that it is not worth the effort for the following reasons:
> > - We don't support comments in the lease files, and I don't think
> that supporting them really makes any sense, because lease file is not
> meant to be edited manually
> > - If the server crashes when it is writing a lease into the lease
> file, and the lease information is incomplete, the server could
> rewrite the incomplete lease to the new file. But, how this incomplete
> entry would be fixed? Manually? By that time the client would probably
> return and get its lease back.
> >
> > However, the most important point is that implementation of this
> capability would require tracking the position of the unparsable data
> in the source lease file so as it will be rewritten in the same
> position (e.g. between lease X and Y) in the output file. At the same
> time, the updated LFC algorithm now loads all leases into memory,
> instead of reading and writing them one-by-one which makes it
> troublesome to match the position of the particular piece of
> unparsable information within the lease data structure, because
> current data structures do not support this capability.
> >
> > Please read the design document: http://kea.isc.org/wiki/LFCDesign
> and report issues on the mailing list.
> >
> > 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.
>



More information about the kea-dev mailing list