BIND 10 #2421: don't reject configuring entire inmemory datasrc due to one broken zone

BIND 10 Development do-not-reply at isc.org
Wed Nov 14 11:53:19 UTC 2012


#2421: don't reject configuring entire inmemory datasrc due to one broken zone
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20121120
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  data   |           Sub-Project:  DNS
  source                             |  Estimated Difficulty:  4
                   Keywords:         |           Total Hours:  0
            Defect Severity:  High   |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:10 muks]:
 > >  * Could there also be unit tests for this, besides lettuce tests?
 >
 > I feel lettuce is the best place for it as this is a bug that shows up
 with bad user configuration. One more check has been added to the lettuce
 test. I think they cover the various cases now. Please see this and if you
 feel that a unit test would cover something and would be needed, I'll add
 it.

 I don't say there should not be the lettuce test. The lettuce test is
 indeed very useful.

 But every piece of code should (at least in theory) be covered by unit
 tests, at least simple ones. You could mock the loader to throw something.

 The reasons to have unit test as well as unit ones are two:
  * Developers usually run unit tests only, not the lettuce tests, during
    development. I suspect not everybody runs lettuce test at least when
    submitting the ticket to review. So unit tests find the problem sooner.
  * When there's a problem, the unit test has smaller scope, so it points
 closer
    to the problem.

 Also, this description:
 {{{
 % DATASRC_LOAD_FROM_ITERATOR_ERROR %1
 An error was found in the zone data when it was being loaded from an
 iterator. The zone was not loaded. The specific error is shown in the
 message, and should be addressed.
 }}}

 I don't know if the user knows enough of the internal to have clue what
 the iterator is. May I suggest to say something like „when it was being
 loaded from another data source“ or „from database“ or something like
 that?

 Also, thinking about it, it might be useful to also log which zone it is
 (in both cases).

 With regards

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


More information about the bind10-tickets mailing list