BIND 10 #2966: ddns should use general datasource configuration, not Auth/database_file

[BIND 10 Development]

#2966: ddns should use general datasource configuration, not Auth/database_file
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  Next-
           Component:  DDNS          |  Sprint-Proposed
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> subject should say all. we'll need this by the time
> we support non-SQLite3 based data source, so it's probably
> the time to schedule it.
>
> More specifics based on #2964:
>
> - import 'data_sources' module instead of 'Auth' as a remote module.
>   See `Xfrin` constructor.
> - maintain `isc.server_common.DataSrcClientsMgr` object and call its
>   reconfigure() from `Xfrin._datasrc_config_handler`
> - when a data source is necessary, get it from the `DataSrcClientsMgr`
>   using its `get_client_list()`.  See xfrin_start().
> - then remove any reference to auth module, "db_file", sqlite3
>   specifics, etc.
>
> In the case of DDNS, I think we'll update the helper
> `isc.ddns.ZoneConfig` so that:
> - it will internally maintain `DataSrcClientsMgr`, instead of taking
>   a specific datasrc_client in the constructor.
> - it will have a new "reconfigure_datasrc()" method, which calls
>   `DataSrcClientsMgr.reconfigure()`
> - its find_zone() will first identify the corresponding data source
>   client list for the class, and then call find() to get the data
>   source client to use.
>
> The main DDNS module will call `ZoneConfig.reconfigure_datasrc()`
> from the remote config update callback for the data_sources module.
>
> DDNS is not threaded, so we don't have to worry about inter-thread
> implications.

New description:

 subject should say all. we'll need this by the time
 we support non-SQLite3 based data source, so it's probably
 the time to schedule it.

 More specifics based on #2964:

 - import 'data_sources' module instead of 'Auth' as a remote module.
   See `Xfrin` constructor.
 - maintain `isc.server_common.DataSrcClientsMgr` object and call its
   reconfigure() from the remote config update callback for the
   data_sources module.  See `Xfrin._datasrc_config_handler`.
 - when a data source is necessary, get it from the `DataSrcClientsMgr`
   using its `get_client_list()`.  See xfrin_start().
 - then remove any reference to auth module, "db_file", sqlite3
   specifics, etc.

 In the case of DDNS, I think we'll update the helper
 `isc.ddns.ZoneConfig` so that:
 - it will internally maintain `DataSrcClientsMgr`, instead of taking
   a specific datasrc_client in the constructor.
 - it will have a new "reconfigure_datasrc()" method, which calls
   `DataSrcClientsMgr.reconfigure()`
 - its find_zone() will first identify the corresponding data source
   client list for the class, and then call find() to get the data
   source client to use.

 The main DDNS module will call `ZoneConfig.reconfigure_datasrc()`
 from the remote config update callback for the data_sources module.

 DDNS is not threaded, so we don't have to worry about inter-thread
 implications.

--

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