BIND 10 #3083: Changes to allocation engine to propagate the information about the FQDNs
BIND 10 Development
do-not-reply at isc.org
Mon Aug 26 13:49:23 UTC 2013
#3083: Changes to allocation engine to propagate the information about the FQDNs
-------------------------------------+-------------------------------------
Reporter: marcin | Owner:
Type: enhancement | marcin
Priority: medium | Status:
Component: dhcp-ddns | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-DHCP-20130904
Sub-Project: DHCP | Resolution:
Estimated Difficulty: 0 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by tmark):
* owner: tmark => marcin
Comment:
Changes here are straight forward. A couple of questions and some
misspellings. Unit tests run cleanly with valgrind, cppcheck looks clean
too.
---------------------------------------------------------------------------
alloc_engine.h
/// engine. In particular, the DHCP server should be able to check
whether
/// existing lease was returned, or new lease was allocated. When
existing
/// lease was returned, server should check whether the FQDN has
changed
/// between the allocation of the old and new lease. If so, server
should
/// perform appropriate DNS update. If not, server may choose to not
/// perform the update. The information about the old lease is
returned via
/// @c old_lease parameter. If NULL value is returned, it is an
indication
General question, should any of the above behavior be configurable?
---------------------------------------------------------------------------
alloc_engine.h
Misspellings "responisibility" and "responibility" in comments for
fwd_dns_update and rev_dns_update parameters.
---------------------------------------------------------------------------
memfile_lease_mgr.cc
Memfile_LeaesMgr::updateLease4 and updateLease6 both warn that the
pointers are not validated. Is this a performance consideration? Almost
everywhere else
in our codebase it seems like we check. The code will crash if they are
invalid. What would Stephen say?
---------------------------------------------------------------------------
--
Ticket URL: <http://bind10.isc.org/ticket/3083#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list