BIND 10 #2013: DDNS config and initial request handling
BIND 10 Development
do-not-reply at isc.org
Fri Jun 1 07:29:26 UTC 2012
#2013: DDNS config and initial request handling
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
jinmei | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20120612
medium | Resolution:
Component: DDNS | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 0
Feature Depending on Ticket: DDNS | Total Hours: 0
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Hello
I'll start with the comments to the branch, I'm going to have a look at
the patch right after that. I'm giving the branch to you now so you can
read the comments sooner.
There's a lot of hardcoding of paths and environment variable handling. I
believe a lot of this functionality is provided by the bind10_config. Is
there a reason not to use it?
I myself usually prefer to get remote spec files from the config manager
by its name instead of the path, it looks like less fragile to me. Just
for my curiosity, is there a reason you prefer to use the path?
In the `get_datasrc_client` function, I believe the
`HARDCODED_DATASRC_CLASS` is not in scope in the except clause, is it?
I don't think I fully understand the comment „it was either totally broken
as an any valid DNS message“.
Does this contain a trick I don't see?
{{{#!python
has_response = False if result == UPDATE_DROP else True
}}}
Or is it just over-complicated way to write?:
{{{#!python
has_response = (result != UPDATE_DROP)
}}}
There are merge markers left in the libddns_messages.mes:
{{{
=======
>>>>>>> 644c706... [1458] cleanup: reorder log message files
}}}
--
Ticket URL: <http://bind10.isc.org/ticket/2013#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list