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-20121023
  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      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:13 vorner]:

 Note: I made one additional editorial cleanup at 86e4008.

 > > {{{#!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.

 I've added the above comment.  Although I don't think the current
 version is particularly more difficult of supporting such incremental
 update, or even in some sense it's now easier due to the simpler form,
 but as long as it's not a blocking issue I won't fight about that.

 > > > 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“:
 [...]
 > 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".

 Okay, I understood what you meant, but I still don't see how that
 applies to this implementation.  If the updated config doesn't contain
 any info about "classes", just nothing will happen (and the server
 will keep running with the current lists) due to this:

 {{{#!cpp
 void
 datasrcConfigHandler(AuthSrv* server, bool* first_time,
                      ModuleCCSession* config_session, const std::string&,
                      isc::data::ConstElementPtr config,
                      const isc::config::ConfigData&)
 {
     assert(server != NULL);
     if (config->contains("classes")) {
 ...
             lists = configureDataSource(config->get("classes"));
     }
 }}}

 Or do I still misunderstand you?

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