<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 6, 2015, at 5:43 AM, Marcin Siodelski <<a href="mailto:marcin@isc.org" class="">marcin@isc.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">All,<br class=""><br class="">I have put together the document<br class=""><a href="http://kea.isc.org/wiki/LeaseExpirationDesign" class="">http://kea.isc.org/wiki/LeaseExpirationDesign</a>, which presents the design<br class="">for the Lease Expiration in Kea 1.0.<br class=""><br class="">This is the first pass for this document and it is still considered<br class="">early draft. In particular there are two sections about extending the<br class="">MySQL and PostgreSQL backend, which are marked "TBD". I am still<br class="">wondering if I should put anything into these sections, given that the<br class="">changes are straight forward and writing what we want to do may take<br class="">more time and actually implementing it. Nonetheless, the document is in<br class="">the shape in which people can review it and provide useful comments.<br class="">Please to so!<br class=""><br class="">Marcin<br class="">_______________________________________________<br class="">kea-dev mailing list<br class=""><a href="mailto:kea-dev@lists.isc.org" class="">kea-dev@lists.isc.org</a><br class="">https://lists.isc.org/mailman/listinfo/kea-dev<br class=""></div></blockquote></div><br class=""><div class="">From Tomek’s mail:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">Approach 3</div><div class="">Everything happens in the main thread. The code is allowed to create new</div><div class="">timers wherever needed, but it must use the IOService created in the</div><div class="">Daemon class. Right now the main DHCPv{4,6} loop calls</div><div class="">LeaseMgrFactory::instance().getIOServiceExecInterval(); to determine the</div><div class="">timeout, but it would call TimerMgr::getTimeout() instead. (That would</div><div class="">also solve the problem described in #3696). That method would go over</div><div class="">all registered timers an find the shortest timeout. That's not a big</div><div class="">deal, as I don't think we'll ever have more than 3 or 4 timers (one for</div><div class="">LFC, second for expiration, maybe a third one for failover and maybe one</div><div class="">more custom for hooks). In this approach, TimerMgr is little more than a</div><div class="">container for timers with couple utility methods. No WatchSocket would</div><div class="">be necessary.</div><div class=""><br class=""></div></blockquote><div class="">I find this approach more appealing in general. For what it’s worth it is also more</div><div class="">like what the current ISC DHCP code does. </div><div class=""><br class=""></div><div class="">How many timers we might have will depend heavily on how much work each timer</div><div class="">is responsible for, but as long as we don’t end up with timers per lease the number</div><div class="">is probably tractable. I believe in the failover case the ISC DHCP code has several</div><div class="">timers per failover peer. Kea could choose a similar approach or could have something</div><div class="">more like one failover timer and the code within that timer would be responsible for</div><div class="">handling all of the items associated with failover.</div><div class=""><br class=""></div><div class="">If we do go with approach 3 we can always start off simple and if we decide to have</div><div class="">a large number of timers in the future move to some sort of list ordered by next timeout</div><div class=""><br class=""></div><div class="">I think adding a brief description of the worker thread for Approach 2 might also be useful</div><div class=""><br class=""></div><div class="">From Thomas’s mail:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">I find "most early" and "least early" confusing phrases. The word</div><div class="">"early" means "before an expected time" or "in the beginning part of an</div><div class="">event".</div></blockquote><div class=""><br class=""></div><div class="">I also find these terms confusing. Thomas’s suggestions are okay, I also like</div><div class="">“less recently used” and “most recently used”.</div><div class=""><br class=""></div><div class="">Other</div><div class=""><br class=""></div><div class="">SKIP FLAG</div><div class="">I am somewhat torn on the skip flag issue. It seems to me that once we have gotten</div><div class="">a lease into the DB we probably should be able to get it out at expire time arguing</div><div class="">against a skip flag on the expiration but I do like all of the hooks being consistent.</div><div class=""><br class=""></div><div class="">In Marcin’s mail on the requirements he had this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">I think we can, at some point, decide that the expired and reclaimed</div><div class="">lease may remain in the database. For example, if the client gets back</div><div class="">to get the new lease, the allocation engine may first check if there is</div><div class="">a lease in the database which the client already used. If the lease gets</div><div class="">removed, there is no way to do it.</div></blockquote><div class=""><br class=""></div><div class="">Well reading the skip flag discussions I was thinking he was considering using</div><div class="">the skip to implement this for address affinity, but as the design document describes</div><div class="">doing so will cause the expiration code to be re-processed every cycle and break</div><div class="">the expiration so I don’t think we can go that route. I think if we want address affinity</div><div class="">we will need another flag or state for the lease to indicate that it is expired but has</div><div class="">already been processed and can be re-used but hopefully only by the current client.</div><div class=""><br class=""></div><div class="">Note that many people do seem to wan address affinity so I think we will need to</div><div class="">consider ways to provide it in the future. (An option that avoids saving state would</div><div class="">be to generate the IP address based on information from the client. This probably</div><div class="">works for v6 with a large address space but probably doesn’t work so well for v4</div><div class="">with it’s smaller address space.)</div><div class=""><br class=""></div><div class="">Do we provide a mechanism for the admin to have a hook send the name change request</div><div class="">to add the name to the DNS?</div><div class=""><br class=""></div><div class="">LOGGING</div><div class="">I see text about a warning message for unwarned-cycles but I don’t see a description of the</div><div class="">message for it, should that be in the doc? </div><div class=""><br class=""></div><div class="">I would also add the number of leases not processed to the RECLAMATION_COMPLETE</div><div class="">message. So something like</div><div class="">RECLAMATION_COPMLETE: time: <execution time>, reclaimed: <number>, didn’t process: <number></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>