[kea-dev] Call for comments about the Lease Expiration design

Marcin Siodelski marcin at isc.org
Mon Jul 27 12:22:48 UTC 2015


Tom,

Thanks for the review. My answers inline.

On 14.07.2015 20:36, Thomas Markwalder wrote:
> On 7/6/15 8:43 AM, Marcin Siodelski wrote:
>> All,
>>
>> I have put together the document
>> http://kea.isc.org/wiki/LeaseExpirationDesign, which presents the design
>> for the Lease Expiration in Kea 1.0.
>>
>> This is the first pass for this document and it is still considered
>> early draft. In particular there are two sections about extending the
>> MySQL and PostgreSQL backend, which are marked "TBD". I am still
>> wondering if I should put anything into these sections, given that the
>> changes are straight forward and writing what we want to do may take
>> more time and actually implementing it. Nonetheless, the document is in
>> the shape in which people can review it and provide useful comments.
>> Please to so!
>>
>> Marcin
>> _______________________________________________
>> kea-dev mailing list
>> kea-dev at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-dev
> Nicely done.
> 
> I find "most early" and "least early" confusing phrases.  The word
> "early" means "before an expected time" or "in the beginning part of an
> event".
> 
> "most early"
> By this you mean, the lease whose expiration date is further in the past
> than any other lease?
> If so, than it is the lease with the  "oldest expiration date" or the
> "most expired". 
> 
> "least early"
> By this you mean, the lease whose expiration date is nearest to the
> present than any other lease?
> If so, than it is the lease with the  "newest expiration date" or the
> "least expired".  So we
> process them in order of oldest expiration to newest expiration, or most
> expired to least expired.
> 
> I would prefer oldest expiration/newest expiration or most expired/least
> expired.
> 

Ok. I don’t object to this change.

> ------------------------------------------
> 
> I think you should at least outline the MySQL/PostgreSQL changes.  If
> there are schema changes, these have ramifications and these should be
> identified.  They would impact db related tools and scripts,
> and adding (or not adding) indexes have performance implications.
> 

Yes. This was the goal. I didn’t do it because of the time defficiency
(upcoming IETF meeting etc.). At the same time I wanted to initite the
design discussion as soon as possible, to gather the feedback prior to
the start of the 1.0 milestone.
I’ll fill this gap in.

> ------------------------------------------
> 
> Leases Reclamation Routine -
> 
> Where you list the operations to be performed by reclamation routines, you
> might want to change the "bullets" to numerals and state that this is
> the order
> they will be performed.  This is relevant when discussing the hook points.
> 

Ok. I’ll do it.

> ------------------------------------------
> 
> New Hook Points/Discussion and skip flag -
> 
> Does it makes sense to honor the skip at all?  Unless they alter the lease
> lifetime or cltt and update the lease in the db (or delete if from the
> db) in their callout,
> skipping reclamation just causes the lease to come up for reclamation on
> the next cycle.
> Other than just honoring it as a matter of ultimate flexibility, I'm not
> sure I see a use-case,
> unless of course they are implementing their own expiration mechanisms.
> 
> If we do decide to honor the skip flag for reclamation hook point, then I
> think it should only be done as all-or-nothing.  Either we reclaim it or we
> skip it.  I don't think it makes much sense to let them delete it from
> the DB
> but skip updating DDNS.  We should also consider creating a statistic for
> reclaim-skips so this can be tracked.    And yes, we would need to clearly
> document the ramifications of skipping a reclamation.
> 

The hooks framework is all about the flexibility of the user and users
may break their own server heavily. But, we have this situation for
other hook points too. I am in favor of letting users implement their
own expiration mechanisms, if they want to. If they don’t want to do it,
they just leave the „skip” flag alone.

Here:
"I don't think it makes much sense to let them delete it from the DB but
skip updating DDNS”.
Did you mean, „Skip updating DDNS but deleting the lease from the DB” ?

> ------------------------------------------
> 
> I agree with your selection of Approach 2, implementing the TimeMgr, though
> you don't really state who/what owns the worker thread in which the
> IOService
> is run.   TimeMgr itself might actually be the best location for this by
> providing a method, runTimerThread(), that when invoked spawns off the
> worker thread which simply invokes io_service_->run().  Similarly, it should
> probably provide a stopTimeThread() method.   For that matter, TimeMgr, if
> so desired could instantiate/use its own IOService instance.
> 

I agree that the clarification is needed.

> Although mentioned under approach 1, You cannot use io_service_->poll in
> a loop,
> as it returns immediately if no handlers are ready, so much of the time
> it would
> just spin like mad and go cpu-bound.
> 

Duly noted.

> ------------------------------------------
> 
> Shouldn't there be an implementation task for retrofitting LFC
> scheduling in the servers
> to use TimerMgr?
> 
> 
> 
> 

Yep. I’ll add one.

Marcin


More information about the kea-dev mailing list