BIND 10 #2204: revise auth DataSourceConfiguratorGeneric::reconfigure()

[BIND 10 Development]

#2204: revise auth DataSourceConfiguratorGeneric::reconfigure()
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121009
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:11 jinmei]:
 > Yeah, I was actually aware of that, and I admit I should mention it.
 > At least for our middle term goals (like for the next beta release) I
 > don't see any benefit to keep complicated interface with possible
 > future extensions.  But if you want to leave some consideration notes
 > on this point, I suggest adding the following to the detailed
 > description for configureDataSourceGeneric():
 >
 > {{{#!cpp
 > /// \note In future we may want to make the reconfiguration more
 efficient
 > /// by only creating newly configured data and just moving the rest from
 > /// the running configuration if they are used in the new configuration
 > /// without any parameter change.  We could probably do it by passing
 > /// the old lists in addition to the new config, but further details are
 > /// still to be defined yet.  It will surely require changes in the
 > /// data source library, too.  So, right now, we don't introduce the
 > /// possibility in the function interface.  If and when we decide to
 introduce
 > /// the optimization, we'll extend the interface.
 > }}}

 OK, let's add the note and leave it this way. Though I had a reasonably
 easy
 approach to do the reuse.

 > > Also, I thought that when there's an update of configuration and the
 top-level
 > > item is unchanged, it is not contained in the update. That is, if we
 added
 > > another item into data_sources besides classes and the new one got
 changed, we
 > > would get an update not containing any classes element. This seems not
 to be
 > > taken into account in the handler in main.cc.
 > >
 >
 > Sorry, I don't understand this.  Could you some specific example?

 OK, let's say we have the data_sources configuration, but because of some
 discussion, besides of classes, we add another item called „zones“:
 {{{
 "data_sources": {
         "classes": {
                 "IN": { something },
                 "CH": { something else }
         },
         "zones": {
                 whatever
         }
 }
 }}}

 Now we do this in bindctl:
 {{{
 config set data_sources/zones "some other thing"
 config commit
 }}}

 The data_sources/classes didn't change. And the config manager AFAIK sends
 only
 something like partial diffs, only the items that were changed ‒ so the
 update
 contains "zones" but does not contain "classes".

 So, the update that does not contain the "classes" item should be ignored.
 In
 the current state, it would either erase all the data sources or crash (I
 didn't really look closely which would happen), which is both bad.

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