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

[Thomas Markwalder]

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.

------------------------------------------

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.

------------------------------------------

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.

------------------------------------------

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.

------------------------------------------

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.

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.

------------------------------------------

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