BIND 10 #1512: implement zone section processing in DDNS

BIND 10 Development do-not-reply at isc.org
Sat May 19 16:54:35 UTC 2012


#1512: implement zone section processing in DDNS
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:  task   |                Status:  reviewing
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120529
                  Component:  DDNS   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:  DDNS   |  Estimated Difficulty:  6
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 I've several technical points.

 First, the distcheck doesn't work, it seems it is missing a file needed
 for tests or some environment variable is not set:
 {{{
 Running test: session_tests.py
 EEEE
 ======================================================================
 ERROR: test_broken_request (__main__.SessionTest)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File
 "/home/vorner/work/bind10/bind10-devel-20120405/_build/../src/lib/python/isc/ddns/tests/session_tests.py",
 line 61, in setUp
     WRITE_ZONE_DB_CONFIG)
 isc.datasrc.Error: Failed to create DataSourceClient of type
 sqlite3:dlopen failed for
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 cannot open shared object file: No such file or directory

 ======================================================================
 ERROR: test_handle (__main__.SessionTest)
 Basic update case
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File
 "/home/vorner/work/bind10/bind10-devel-20120405/_build/../src/lib/python/isc/ddns/tests/session_tests.py",
 line 61, in setUp
     WRITE_ZONE_DB_CONFIG)
 isc.datasrc.Error: Failed to create DataSourceClient of type
 sqlite3:dlopen failed for
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 cannot open shared object file: No such file or directory

 ======================================================================
 ERROR: test_update_notauth (__main__.SessionTest)
 Update attempt for non authoritative zones
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File
 "/home/vorner/work/bind10/bind10-devel-20120405/_build/../src/lib/python/isc/ddns/tests/session_tests.py",
 line 61, in setUp
     WRITE_ZONE_DB_CONFIG)
 isc.datasrc.Error: Failed to create DataSourceClient of type
 sqlite3:dlopen failed for
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 cannot open shared object file: No such file or directory

 ======================================================================
 ERROR: test_update_secondary (__main__.SessionTest)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File
 "/home/vorner/work/bind10/bind10-devel-20120405/_build/../src/lib/python/isc/ddns/tests/session_tests.py",
 line 61, in setUp
     WRITE_ZONE_DB_CONFIG)
 isc.datasrc.Error: Failed to create DataSourceClient of type
 sqlite3:dlopen failed for
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 /home/vorner/work/bind10/bind10-devel-20120405/_inst/libexec/bind10-devel/backends/sqlite3_ds.so:
 cannot open shared object file: No such file or directory

 ----------------------------------------------------------------------
 Ran 4 tests in 0.002s

 FAILED (errors=4)
 make[9]: Leaving directory
 `/home/vorner/work/bind10/bind10-devel-20120405/_build/src/lib/python/isc/ddns/tests'
 }}}

 The `test_hash` ‒ as the hashes returned by it are deterministic, we could
 find a pair of names that return different values and check it.

 `LIBDDNS_UPDATE_FORWARD_FAIL` ‒ „This is not necessarily mean invalid,“ ‒
 maybe the „mean“ is extra?

 The description of `LIBDDNS_UPDATE_NOTAUTH` is confusing. Does have or
 does not have authority?

 What is the motivation to have classes for formatting data
 (`ZoneFormatter` and `ClientFormatter`)? If it is performance, is it
 really faster to allocate the new python object than to do the actual
 conversion?

 The `req_data` parameter is not handled in `UpdateSession.__init__`.

 Should the `return UPDATE_ERROR, None, None` be inside the `except`? This
 looks like it is common for both successful and unsuccessful code flow,
 but the successful one returns before that, I think this might be
 confusing.

 In the session tests, what is the purpose of the `toText()` calls?
 Shouldn't the objects be directly comparable?
 {{{#!python
         self.assertEqual(Opcode.UPDATE().to_text(),
 msg.get_opcode().to_text())
         self.assertEqual(expected_rcode.to_text(),
 msg.get_rcode().to_text())
 }}}

 The comment is missing an „s“:
 `secondaries: a list of 2-element tuple`

 Would it be better to use `set` instead of dict here? Or is it expected to
 contain something else than `True` values?
 {{{#!python
     self.__secondaries = {}
         for (zname, zclass) in secondaries:
             self.__secondaries[(zname, zclass)] = True
 }}}

 How will the zone config handle different classes if it can hold only one
 data source? Is it expected to hold multiple zone configs then?

 It'll look up a zone twice (once to check it contains the zone and another
 time when the handling will happen). Is it OK?

 Are there no tests for the zone config? Or is it expected to be really
 short-term?

 Thanks

-- 
Ticket URL: <http://bind10.isc.org/ticket/1512#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list