BIND 10 #948: old Xfrin/master_addr configuration is in the way

[BIND 10 Development]

#948: old Xfrin/master_addr configuration is in the way
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  major         |                    Milestone:  New
           Component:                |  Tasks
  configuration                      |                     Keywords:
           Sensitive:  0             |              Defect Severity:  N/A
         Sub-Project:  DNS           |  Feature Depending on Ticket:
Estimated Difficulty:  0             |          Add Hours to Ticket:  0
         Total Hours:  0             |                    Internal?:  0
-------------------------------------+-------------------------------------
 This is related to #945.

 zone-related info is in xfrin, not zonemgr. master_addr is not directly in
 xfrin anymore, but one of the values of Xfrin/zones.

 If you have old configuration in place, it gets in the way:

 {{{

 > config show Xfrin
 Xfrin/transfers_in      10      integer (default)
 Xfrin/zones     []      list    (default)
 > config show_json Xfrin
 {"master_addr": "192.168.1.1"}

 }}}

 I think something should loudly complain.

 And now bindctl is showing two different sets of values and doesn't tell
 me which is real.

 jelte says I think we should have per-module config version numbers.

 Here is an example of problem:

 {{{
 > config show_json Xfrin
 {"master_addr": "192.168.1.1"}
 > config add Xfrin/zones
 > config set Xfrin/zones[0]/name foo
 > config set Xfrin/zones[0]/master_addr 192.168.1.1
 > config diff
 {'Xfrin': {'zones': [{'name': 'foo', 'master_addr': '192.168.1.1'}]}}
 > config commit
 Error: unknown item master_addr
 Configuration not committed
 > config show_json Xfrin
 {"zones": [{"name": "foo", "master_addr": "192.168.1.1"}]}
 > config diff
 {'Xfrin': {'zones': [{'name': 'foo', 'master_addr': '192.168.1.1'}]}}

 }}}

 Looks like "show_json" shows what is not committed yet.

 It does complain, only way too late.

 Jelte said "afraid the only quick workaround is to stop bind10 and
 manually remove that original master_addr from b10-config.db".

 So that is what I did.

 Manually editing the config database is not what we want to do so I am
 opening ticket.

-- 
Ticket URL: <http://bind10.isc.org/ticket/948>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development