Changes between Version 10 and Version 11 of April2013DhcpDdns


Ignore:
Timestamp:
Apr 25, 2013, 12:17:56 PM (5 years ago)
Author:
stephen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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.
    5757
    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.
    5959
    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.
    6363
    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.)
    6565
    6666Shawn: not to add update-optimization when we start.
     
    6969Part 2 (Friday)
    7070
    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).
    7272
    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.
    7474
    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).
    7676
    77 Stephen will upload whiteboard photos.
     77The class !LeaseChange should be renamed !NameChange
    7878
    79 LeaseChange => NameChange
     79The state diagram is only concerned with updating a single name.  There are several issues with it:
     80
     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)
     84
     85A "superstate" transition diagram is probably needed to address these.
    8086
    8187=== Whiteboard photo from Friday's session: