BIND 10 #3059: Create initial UpdateMgr class

BIND 10 Development do-not-reply at isc.org
Wed Aug 7 08:24:25 UTC 2013


#3059: Create initial UpdateMgr class
-------------------------------------+-------------------------------------
            Reporter:  tmark         |                        Owner:  tmark
                Type:  enhancement   |                       Status:
            Priority:  medium        |  reviewing
           Component:  dhcp-ddns     |                    Milestone:
            Keywords:                |  Sprint-DHCP-20130731
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by marcin):

 * owner:  marcin => tmark


Comment:

 Replying to [comment:6 tmark]:
 > Replying to [comment:5 marcin]:
 > > '''src/bin/d2/d2_config.cc'''
 > > matchDomain: Why do you have to reset the domain pointer on the
 function entry? I suggest that the pointer provided by the caller is not
 modified if there is no match. I would understand that the pointer is
 reset if there was no boolean value return which signals that the match
 was found. You could choose to signal no match with NULL pointer. Since,
 you have the return value there is no need to modify the pointer, allowing
 the caller to use it further if there was no match.

 This hasn't been addressed. Please let me know what you think.

 > >
 > > Instead of using raw (unsafe) strings and memcmp you could use
 std::string objects and use equality operator and .compare function like
 this:
 > Done.

 Actually, it could be further simplified by removing the req_name and use
 fqdn instead. I committed the change to the branch. Please pull the
 change.

 > >
 > > Are there any functions in UpdateMgr that should be private? For
 example, I can see that the checkFinishedTransactions is called internally
 by sweep(). There is a question if it will be also called externally? Same
 for pickNextJob().

 This hasn't been addressed.

 > >
 > > '''src/bin/d2/tests/d2_cfg_mgr_unittests.cc'''
 > > checkServer: Why not declare checkServer as void and perform
 !''expects!'' there like this:
 > >
 > > {{{
 > >     EXPECT_TRUE(server);
 > >
 > >     // Check hostname.
 > >     EXPECT_EQ(hostname, server->getHostname());
 > > ...
 > > }}}
 > > etc. ?
 >
 > Because the  test log output is less precise that way.  If I do as you
 suggest
 > the log loosk about like this:
 >
 > {{{
 > [ RUN      ] DdnsDomainTest.DdnsDomainListParsing
 > d2_cfg_mgr_unittests.cc:100: Failure
 > Value of: server->getPort()
 >   Actual: 500
 > Expected: port
 > Which is: 700
 > [  FAILED  ] DdnsDomainTest.DdnsDomainListParsing (0 ms)
 > }}}
 >
 > The way it is written now, the log looks like this on a failure:
 >
 > {{{
 > d2_cfg_mgr_unittests.cc:100: Failure
 > Value of: server->getPort()
 >   Actual: 500
 > Expected: port
 > Which is: 700
 > d2_cfg_mgr_unittests.cc:827: Failure
 > Value of: checkServer(server, "", "127.0.0.5", 700)
 >   Actual: false
 > Expected: true
 > }}}
 >
 > Notice that you can easily see where it failed.  This is helpful when
 there are many
 > calls to the same method in many tests.  I actually could make it return
 an Assertion result
 > which is a technique I only recently learned.  However, at this point in
 the schedule there are more pressing things to do and these tests all
 function correctly.

 Fair enough. One comment regarding !''However, at this point in the
 schedule there are more pressing things to do and these tests all function
 correctly.!'' I am sure there will never be a good time to fix things like
 this. In other words, if you're planning to change this to
 !''!AssertionFailure approach!'' I suggest that it is rather done today.
 If you  don't do it today, I bet it will remain like this forever. There
 is a general practice among all developers to say !''we will fix it
 later!'' and 90% of these things are never fixed.

 In general. I now understand the motivation and I will not insist that you
 change it.


 Regarding the !ChangeLog. Shouldn't it be: !''This class '''is''' the
 DHCP_DDNS task master,
 instantiating and supervising transactions that carry out the DNS updates
 needed to fulfill the requests (!NameChangeRequests) received from
 DHCP_DDNS
 clients (e.g. DHCP servers).!'' ?

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


More information about the bind10-tickets mailing list