BIND 10 #2672: Go through message IDs saying ERROR and check at which level they are logged

[BIND 10 Development]

#2672: Go through message IDs saying ERROR and check at which level they are
logged
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  logging       |                    Milestone:
            Keywords:                |  Sprint-20130219
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  3             |              Defect Severity:  N/A
         Total Hours:  0.48          |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks
 * totalhours:  0 => 0.48


Comment:

 Hello

 Replying to [comment:3 muks]:
 > * I have left IDs logged at FATAL to contain ERROR in some places as
 >   there's no better way to say it:
 > {{{
 >     logger.fatal(BIND10_SELECT_ERROR, err)
 >     logger.fatal(BIND10_SOCKCREATOR_TRANSPORT_ERROR, str(se))
 >     logger.fatal(BIND10_STARTUP_ERROR, startup_result)
 >     logger.fatal(CMDCTL_CC_SESSION_ERROR, err)
 >     logger.fatal(STATSHTTPD_CC_SESSION_ERROR, se)
 >     logger.fatal(STATS_START_ERROR, se)
 >     logger.fatal(STATSHTTPD_START_SERVER_INIT_ERROR, hse)
 >     logger.fatal(STATS_CC_SESSION_ERROR, se)
 >     logger.fatal(STATS_START_ERROR, se)
 >     LOG_FATAL(logger, CC_CONN_ERROR).arg(se.what());
 >     LOG_FATAL(logger, CC_WRITE_ERROR).arg(asio_ex.what());
 >     logger.fatal(CFGMGR_CC_SESSION_ERROR, se)
 >     logger.fatal(CFGMGR_DATA_READ_ERROR, cmdre)
 > }}}

 I think these are not confusing, fatals are errors of kind too (even if it
 doesn't explicitly say error in the severity).

 > * I've also left `LOG_READ_ERROR` and `LOG_WRITE_ERROR` in the logger
 >   test code as-is. They are used in multiple places there with different
 >   severity levels for testing.

 That seems OK too, as user won't meet these.

 > * The following (logged at DEBUG) were also untouched, as they seem to
 >   have the right IDs:
 > {{{
 > % NSAS_ERROR_RESPONSE error response of %1 returned in query for %2
 > The NSAS (nameserver address store - part of the resolver) made a query
 > for information it needed.  The query completed successfully but the
 > RCODE in the response was something other than NOERROR.
 >
 > % RESLIB_ERROR_RESPONSE unspecified error received in response to query
 for <%1>
 > A debug message, the response to the specified query to an upstream
 > nameserver indicated that the response was classified as an erroneous
 > response, but that the nature of the error cannot be identified.
 > A SERVFAIL will be returned to the system making the original query.
 > }}}

 I guess it is reasonable too. As the error is not at the end, we just
 received an error response (which is not an error by itself).

 > * `ChangeLog` is required:
 > {{{
 > +XYZ.   [func]          muks
 > +       Various message IDs have been renamed to remove the word 'ERROR'
 > +       from them when they are not logged at ERROR severity level.
 > +       (Trac #2672, git ...)
 > +
 > }}}

 OK

 The lettuce tests failed for me, but they don't if I merge with master, so
 I guess it's some kind of unrelated problem. This can be merged.

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