BIND 10 #2967: zonemgr should use general datasource configuration, not Auth/database_file

BIND 10 Development do-not-reply at isc.org
Fri Jun 28 14:39:12 UTC 2013


#2967: zonemgr should use general datasource configuration, not Auth/database_file
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  pselkirk
            Priority:  medium        |                       Status:
           Component:  xfrin         |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130709
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => pselkirk


Comment:

 Hello

 I know it was recommended, but I believe cherry-pick is reasonable for one
 or two commits, not for half of the whole branch. The cherry-picked
 commits are duplicates in history, which is not nice in case the history
 needs to be examined. Would it be OK to rebase the branch on top of master
 once the #2854 is merged (it should be any time soon)?

 And, now the usual bunch of nitpicking:

 What is the reason for these things?

 {{{#!python
         self.zone_refresh._get_zone_soa = old_get_zone_soa
 }}}

 This seems unnecessary, since new `zone_refresh` should be created for
 each test, so it is not needed to restore it. If a new one is not created,
 the tests could influence each other, which is bad.

 {{{#!python
         self.assertRaises(ZonemgrException,
 self.zone_refresh.zone_refresh_success, ("example.test.", "CH"))
         self.assertRaises(ZonemgrException,
 self.zone_refresh.zone_refresh_success, ZONE_NAME_CLASS3_IN)
         rdata_net = old_rdata_net
 }}}

 It feels very hackish to overwrite the rdata_net global variable. As it is
 sitting at the top of the file, the impression it does is it is a
 constant. We do these things to other modules from tests, to inject mock
 ups, but it seems it should be possible to do it in a cleaner way if it is
 the same module. Also, if one of the asserts fails, the value is not
 restored, which will break other tests.

 {{{#!python
     def tearDown(self):
         pass
 }}}

 This is unnecessary. The tearDown method is optional, there's no need to
 have an empty one there.

 When folding the long lines, it might be useful to know that the backslash
 is not needed if it is inside of parentheses, like here (but there are
 many other cases as well):

 {{{#!python
         self._set_zone_next_refresh_time(zone_name_class,
                                          self._get_current_time() + \
                                              self._random_jitter(max,
 jitter))
 }}}

 Also, python does not need parentheses around conditionals and when seen
 in the code, pythonists wonder what the catch there is:

 {{{#!python
             if (zone_soa == None):
 }}}

 Looking at this code, strong deja-vu feeling hangs in the air. I'd say
 I've seen such code somewhere (maybe some kind of isc.utils library).
 {{{#!python
             def format_zone_str(zone_name, zone_class):
                 """Helper function to format a zone name and class as a
 string
                 of the form '<name>/<class>'.
                 Parameters:
                 zone_name (isc.dns.Name) name to format
                 zone_class (isc.dns.RRClass) class to format
                 """
                 return zone_name.to_text(True) + '/' + str(zone_class)
 }}}

 I'd say a zone without SOA might be legal (for example empty), but it
 still is suspicious situation. Should this be a warning instead of info?
 {{{#!python
             if result != ZoneFinder.SUCCESS:
                 logger.info(ZONEMGR_NO_SOA, format_zone_str(zone_name,
 zone_class))
                 return None
 }}}

 I don't think it is in the scope of the ticket, but we may want to be able
 to specify the datastore name for a configured zone too. This does not
 seem to support that, maybe some kind of comment would be in place?:
 {{{#!python
         clist =
 self._datasrc_clients_mgr.get_client_list(zone_name_class[1])
 }}}

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


More information about the bind10-tickets mailing list