BIND 10 #2380: revise b10-loadzone using datasrc.ZoneLoader
BIND 10 Development
do-not-reply at isc.org
Mon Dec 17 16:50:59 UTC 2012
#2380: revise b10-loadzone using datasrc.ZoneLoader
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: task | jinmei
Priority: medium | Status:
Component: loadzone | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-20121218
Sub-Project: DNS | Resolution:
Estimated Difficulty: 8 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| loadzone-ng
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by jelte):
* owner: jelte => jinmei
Comment:
General:
While it is probably the most flexible approach, I don't think we should
force people to enter JSON on the command line in order to load a zone...
Perhaps we can also add an option to only specify an sqlite3 file and
create the config magic ourselves (leaving the current option for other
datasources), e.g. has a -s <sqlite3-db-file> if -t is sqlite3 or not
given (a bit similar to how logging 'config' is done now, and for the
user, similar to the old -d option).
And/or, but that may be something to add later, if it can find the
'global' bind10 configuration file, it could in theory figure out if there
is something configured (and, say, pick the first one that supports
loading) but in the near future this would also require a hackish
approach, as it would have to untangle the json file itself. Regarding
that, if this replaces the existing loadzone now, the TODO file is not
completely right).
On another topic, ye olde loadzone printed how many RRs were loaded, and
how long it took. I realize the current API does not support the former
well, but I wonder if it would be worth it to bring that back. It's kind
of nice to affirm you're not suddenly loading a 2-record zone :) It still
does so if you use -i 1, but unless specifically disabled, I'd love to see
the final result report (mainly, the count for the last 'iteration' is
obviously missing for any value > 1).
In the usage() output (optparse help), we should probably add something
like [0-99] for the debug level option (and come to think of it, perhaps a
silent mode, or rather, only WARN and ERROR).
Tests fail for me (I build with --prefix but without installing):
{{{
isc.datasrc.Error: Failed to create DataSourceClient of type
sqlite3:dlopen failed for
/home/jelte/opt/bind10/libexec/bind10-devel/backends/sqlite3_ds.so:
/home/jelte/opt/bind10/libexec/bind10-devel/backends/sqlite3_ds.so: cannot
open shared object file: No such file or directory
}}}
(a whole bunch of them and other errors, all of which I assume because of
this)
I guess the Makefile needs to set B10_FROM_BUILD to get the correct
dynamic loading dir.
loadzone.py.in:
is the if necessary here?
{{{
if self._load_iteration_limit > 0:
limit = self._load_iteration_limit
else:
limit = LOAD_INTERVAL_DEFAULT
}}}
( !__init!__ already defaults to LOAD_INTERVAL_DEFAULT, as does the
optparse code, so it certainly looks like it should be able to always use
self._load_iteration_limit)
Overwriting the same line with \r in !__report_progress() is cute,
however, we do need a \n somewhere :) (probably before if
self.!__interrupted around line 240)
maybe a matter of taste, but should we not consider a zone without a SOA a
complete failure and error/revert on it?
--
Ticket URL: <http://bind10.isc.org/ticket/2380#comment:9>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list