BIND 10 #922: Callback for foreign module configuration

BIND 10 Development do-not-reply at isc.org
Mon May 16 16:10:38 UTC 2011


#922: Callback for foreign module configuration
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110517
                  Component:         |            Resolution:
  configuration                      |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 A few comments for now, and I have a few i want documented somewhere so as
 not to forget.

 Think this was already a problem, but easy to remedy now; we should move
 the subscribe() call down until after the last possible exception (or
 unsubscribe() before we throw) in the add_remote() call, so that we don't
 end up with 'loose' subscription if something goes wrong in the setup.

 Do we have/want a strict requirement that module names don't contain dots?
 They can't contain / due to another implementation limitation right now.
 If we do not have or want such a requirement, perhaps we should have two
 separate methods for adding them either with a module name or a file name.
 (Also, not necessarily a problem, but we should be aware of it: using a
 module name instead of a specfile means that said module has to be running
 (so that it is known for config manager) right now. Hopefully we can make
 this problem disappear soonish :)))

 Can you add a bit of text to the documentation that the handler should
 never throw? (or, alternatively, catch any exception when calling it, so
 that update and init do not bail out should the handler throw an
 exception)

 And a few general comments that we should probably create tickets for:

 There is a separate python implementation for ccsession etc. we should add
 this callback functionality there too (can be a separate ticket so as not
 to block the other tickets that depend on this one).

 This was already a potential problem, and solving it will probably require
 some internal protocol change, but if an updated configuration is rejected
 by a module, I don't think the modules that are peeking in on its config
 values are notified of this. Same as for previous point, as this was
 already a problem, we should probably make this a ticket.

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


More information about the bind10-tickets mailing list