BIND 10 #810: TSIG: Create non-module config location support

[BIND 10 Development]

#810: TSIG: Create non-module config location support
-------------------------------------+-------------------------------------
                 Reporter:  stephen  |                Owner:  stephen
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:
                 Priority:  blocker  |  Sprint-20110419
                Component:           |           Resolution:
  Unclassified                       |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  2.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => stephen


Comment:

 Hello

 Replying to [comment:10 stephen]:
 > '''src/lib/python/isc/config/cfgmgr.py'''[[BR]]
 > Comment: rather than use an array of virtual modules and an array of
 real modules, and branching on which one contains the module being
 considered, can't we encapsulate a module in a class and use different
 derived classes for "real" and "virtual" modules?  It would aid future
 extensibility.

 Actually, that would be little harder, than it seems. For one, there's no
 array (well, they are dicts, but its not important) with real modules.
 There's one dict where the configuration data (of all modules) live. They
 are, however, simple python structures (dicts and lists), not classes. So
 changing these would require quite deep refactoring of the whole config
 manager, which I don't really like.

 Then there's the dict with virtual modules. Yes, I probably could say that
 every module is equivalent to current virtual and place a function to post
 the config over the msgq there. But the posting has slightly different
 „natural“ interface, than the function and would be playing with words
 mostly (and the difficulty of distinguishing between real and virtual
 modules would just be placed somewhere else).

 And anyway, I don't see the extensibility it would bring. The virtual
 module contains a callable object, so any behaviour can be placed there if
 needed in future. And the I think we usually do as little work as
 possible, until the extensibility is needed. In the case it is needed, it
 can be changed then? But I simply think it doesn't fit into current design
 without a rework and the rework would make it only needlessly complicated.

 Anyway, I think the config manager has some incorrect behaviour now (in
 the case one module rejects the configuration, odd things can happen).
 When these are solved, I could imagine placing something more generic
 there would be much easier. So, would you agree with a # TODO comment
 there, explaining the problems and possible solution?

 > Some documentation on how to create a plugin would be helpful - either
 on the wiki or as a README in the configuration manager directory.  The
 comments in "testplugin.py" are a bit sparse, and it is not the most
 obvious place for documentation.

 I placed a README into the plugins directory, with small example. Anyway,
 I hope we'll create a configuration plugin soon, so we would have a real
 example as well.

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