BIND 10 #3360: memfile: implement file support

[BIND 10 Development]

#3360: memfile: implement file support
-------------------------------------+-------------------------------------
                   Reporter:  tomek  |                 Owner:
                       Type:         |                Status:  new
  enhancement                        |             Milestone:  DHCP-Kea-
                   Priority:         |  proposed
  medium                             |              Keywords:
                  Component:         |             Sensitive:  0
  dhcpdb                             |           Sub-Project:  DHCP
               CVSS Scoring:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 Currently memfile does not support reading or writing. This work is about
 adding read/write support for that backend.

 Marcin and Tomek did a rough design discussion. It is likely to be a CSV
 file, because of its simplicity and editability (users can use automated
 tools like grep, awk, sed, but also edit the database using Excel if they
 want to).

 One thing to remember here is that possibly the lease database will store
 additional information (including options). Leasequery RFC says that
 server MAY return options sent to the client. One day a customer may ask
 for that feature. That list will be much longer than just client FQDN.

 Another question is whether we want to use:
 a) ISC DHCP approach (append updated lease to the end)
 b) write full database.

 a) is faster, because only a single line is written when lease changes. It
 has a disadvantage of requiring periodic (e.g. once per hour) rewrite of
 the whole database. It is also less readable for users, as specific logic
 has to be used (if a given lease is mentioned several times, only the last
 entry is applicable).

 b) it is simpler and easier for users to understand. It has an obvious
 disadvantage of not scaling well if the whole database is written.

 There is a question whether the whole database should be written to disk
 every time a lease changes (and if so, whether Kea should flush disk
 cache).  Another approach could be to read DB at the startup and write it
 back at shutdown. Less resilient, but blazingly fast.

 Probably we will ultimately have a knob which will alllow tweaking the
 behavior to meet all of the above.

 Not everything mentioned here will be done in this ticket. As a bare
 minimum, it must cover reading and writing data to disk, it doesn't have
 to be super optimized from day 1.

 Before this tickets is started, #3359 (common unit-tests for backends)
 should be done.

-- 
Ticket URL: <http://bind10.isc.org/ticket/3360>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development