BIND 10 #99: bindctl will allow options for modules that aren't running

[BIND 10 Development]

#99: bindctl will allow options for modules that aren't running
---------------------------+------------------------------------------------
      Reporter:  jreed     |        Owner:  zhanglikun                                    
          Type:  defect    |       Status:  assigned                                      
      Priority:  major     |    Milestone:  05. 3rd Incremental Release: Serious Secondary
     Component:  bind-ctl  |   Resolution:                                                
      Keywords:            |    Sensitive:  0                                             
Estimatedhours:  0.0       |        Hours:                                                
      Billable:  0         |   Totalhours:                                                
      Internal:  0         |  
---------------------------+------------------------------------------------

Comment(by jelte):

 Replying to [comment:6 zhanglikun]:
 > How you plan to let it return an error? since configmanager or cmdctl
 doesn't know it now.
 >

 If we limit configuration options to running modules (for now!) cfgmgr
 could simply send back an error message when it gets an config-update
 command. But I was thinking of letting bindctl not send it in the first
 place (i.e. do a key check when 'config set' is entered)

 > BTW, I have some comments about the operation for configuration.
 >
 > 1. For the low-level configuration item, maybe it's not easy to config
 it by bindctl, like I want to change one port of the master, the commmand
 will like "config set xfrin/masters[2]/port 53", I don't know whether we
 will provide lower level config items.
 >

 Yes we definitely need that, but i think we need something a little bit
 more advanced than simply an index (i was thinking of something like
 "config set xfrin/masters[zone_name='example.com']/port 53"

 Ideas are very welcome :)

 > '''
 > {
 >    module_name: 'xfrin':
 >    [
 >        {
 >          masters: [
 >             { 'ip':1.1.1.1, 'port':53 }
 >             { 'ip':2.2.2.2, 'port':12345 }
 >             { 'ip':3.3.3.3, 'port':12345 }
 >          ]
 >        }
 >    ]
 > }
 > '''
 >
 >
 > 2. I am not sure whether the 'static' configuration APIs can handle the
 "big" configuration operation, like I want to set several 'masters' for
 more than one zone, I had thought it can be down through bindctl, but it
 really frustrating, because I have to 'config set master 1.1.1.1, then
 config commit" again and again. It's better let user to write the
 configuration in one file, then load it to config manager. (We talked it
 in beijing f2f meeting.)

 bindctl should be able to handle entire subtrees of configuration
 directly, and you should not need to commit after every addition (if
 either of these things is not true we have a bug)

 having batch-operations taken from a file would be another feature we
 should definitely implement

 The reason i am talking about a 'static' configuration API is that we
 might also want to change configuration when BIND10 is not running at all.
 In that case we'll need a way to find out what modules and configuration
 options exist, and that is what we'll need for 'live' changes to non-
 running modules here too.

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