BIND 10 #1074: Use debug levels consistently

[BIND 10 Development]

#1074: Use debug levels consistently
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20111025
                   Priority:  minor  |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jelte


Comment:

 > log_dbglevels.h: don't know yet if i completely agree with the intro,
 but practice may have to show that. For instance, "covers things like
 startup-steps and config messages", i think it should also be things like
 bad responses from nameservers that do not interrupt operations, but may
 be useful for fixing bigger setups etc. from that would follow that 30<
 for applications, and 30> for libraries may be too strict a definition.
 Things like bad responses from nameservers can certainly be included in
 the category "useful to an administrator".  If 30 is too low a value to
 distinguish between categories, we can certainly shift the boundary.

 The idea of "useful to an administrator" was to signal the to the user
 that it is no use in setting the debug level too high, as the messages
 that come back are likely to be of no use unless you understand the code,
 and so will only clog up your log file.

 > if such things are to be DEBUG as well, we probably need to add one or
 more consts for it as well, but we'll see that when we get there (may
 become more relevant once we refocus on resolver)
 The current set of constants were created looking at the levels defined in
 the various modules.  I certainly don't think they are completely correct,
 and they may need to be "tuned" as development progresses.  Also, I think
 it is entirely likely that we will add more levels.  However, bear in mind
 that if we want to track a particular category of conditions, we could
 always do that via a separate logger using one of the standard debug
 levels.

 > changed "N.B." to "\note" btw. (and removed a few spaces), please verify
 commit.
 Thanks.

 > Should we consider replacing the module-specific levels with the general
 ones everywhere?
 I thought of that, but what decided me against it was:
 1. The possibility that at some time we change the relative numbers of the
 general constants, which in turn may need some modules having their debug
 levels modified.  With the indirection of module-specific levels, there is
 just one place where changes will need to be made.
 1. The possibility that modules may want to define custom levels (e.g. a
 "trace intermediate").  In that case they would use a combination of
 general debug level constants and module-specific ones.  It seemed cleaner
 to have all the levels for a module defined in one place.

 > Would we want to check all constants in log_test.py? (not sure)
 I didn't do that in case we ever changed some of the values (so would have
 to alter the tests).  The main reason for a test of the value of one of
 the constants was to ensure that the definitions added to the .cc file
 were OK.

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