BIND 10 #2020: b10-ddns should get a list of secondary zones from zonemgr

[BIND 10 Development]

#2020: b10-ddns should get a list of secondary zones from zonemgr
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120619
  medium                             |            Resolution:
                  Component:  DDNS   |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:  DDNS   |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:6 jelte]:

 Thanks for the review.

 > Just wondering, have you considered waiting for a bit and trying again
 if get_remote_config fails (obviously with a real propagated error if it
 still doesn't work after X attempts)?
 >
 > Since the module should have already announced its own existence there
 should be no deadlock there, and while forcing its own restart may work,
 it might stop working if we implement automatic unregistering modules that
 die (unless we get to implementing config/remote config for non-running
 modules first).

 Hmm, I didn't consider that option.  We discussed on jabber the idea
 of imposing a delay before calling add_remote, but I didn't like to
 add possibly unnecessary delay.  Adding waiting periods after failure
 seems to make more sense, so I revised the code that way.

 I don't understand the automatic unregistering thing though - unless
 someone depends on ddns I don't think it matters even if ddns dies on
 failing to get remote config and unregisters itself.  And, if someone
 else starts depending on ddns and ddns depends on it, I think it's
 time to consider more sophisticated solution anyway because what's
 needed from ddns may not just be configuration - it may be interaction
 via command channels, which can only start after all initial setups
 are done.

 > The code itself seems ok, just a few comment nits:
 >
 > ddns.py.in:
 > - typo on line 202 (propagte)

 Oops, fixed it.

 > - line 318: '# class is optional per spec.' I guess that should say 'not
 optional' which would make the rest of the comment make more sense too :)

 Ah, that "optional" thing always confuses me (actually, the concept of
 "optional" may not be that confusing, but the combination of optional
 and "default" is probably the source of confusion).  I hope we'll give
 them better names in the config-ng.

 Also, for both this one and add_remote failure, I ended up exploring
 the maze of configuration stuff further, and found other some weird
 things that I misunderstood.  They didn't affect too much to ddns
 itself, but I clarified these points in comments and created a couple
 of related new tickets (#2038 and #2039).

-- 
Ticket URL: <https://bind10.isc.org/ticket/2020#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development