Changes between Version 10 and Version 11 of April2013DhcpDdns

Apr 25, 2013, 12:17:56 PM (5 years ago)



  • April2013DhcpDdns

    v10 v11  
    5656The decision code will be implemented as a separate class just in case we want to move it to the DDNS module. This is only a relatively simple question: should we try to do the update or not? "Fire & forget" approach.
    58 It is very likely that we'll use boost interprocess routines for dhcp->ddns module communication.
     58It is very likely that we'll use boost::interprocess routines for DHCP->DDNS module communication.
    6060Marcin: we need to track lease expiration in the database.
    6262We do not support lease expiration yet - we can't take any actions. This is required to for legal reasons and to trigger DDNS removal. We need nanny/housekeeper process.
    64 This will work well with MySQL. What about sqlite or memfile? 2 separate processes access the same database = problems.
     64This will work well with MySQL. What about SQLite or memfile? In these cases, two separate processes accessing the same database will give problems. (Table locking in the case of SQLite3, and the requirement for shared memory in the case of Memfile.)
    6666Shawn: not to add update-optimization when we start.
    6969Part 2 (Friday)
    71 Marcin: let's get back to the topic of having 2 tables (one for leases and second for ddns updates).
     71Marcin: let's get back to the topic of having 2 tables (one for leases and second for DDNS updates).
    73 DHCP server will keep the fqdn information in the
     73DHCP server will keep the FQDN information in the database.  However, persistence of the DDNS queue is a priority 2 item: for the first implementation, it will be OK if the queue information is just held in memory.
    75 Conflict detection (and reporting failures from ddns back to dhcp is not interesting for now, we'll may reconsider when people will ask for it)
     75Conflict detection (and reporting failures from DDNS back to DHCP is not interesting for now: we may reconsider when people will ask for it).
    77 Stephen will upload whiteboard photos.
     77The class !LeaseChange should be renamed !NameChange
    79 LeaseChange => NameChange
     79The state diagram is only concerned with updating a single name.  There are several issues with it:
     81* There are linked transactions within an update (e.g. try adding a name with pre-requisties, then unconditional addition etc.)
     82* The server should not be changed within a transaction (if the first operation succeeds but the second fails).
     83* There are multiple transactions (i.e. adding a name to the forwards zone, then a name to the reverse zone)
     85A "superstate" transition diagram is probably needed to address these.
    8187=== Whiteboard photo from Friday's session: