Opened 9 years ago

Closed 9 years ago

#735 closed task (complete)

Investigate BIND-9 Logging

Reported by: stephen Owned by: stephen
Priority: high Milestone: Sprint-20110503
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket: logging
Estimated Difficulty: 4.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Examine the BIND-9 logging code to see if it can be re-used in BIND-10. (The aim would be to have a common logging library between the two products.)

Subtickets

Change History (10)

comment:1 Changed 9 years ago by stephen

  • Type changed from defect to task

comment:2 Changed 9 years ago by shane

  • Milestone changed from Year 3 Task Backlog to Sprint-20110419

comment:3 Changed 9 years ago by shane

  • Priority changed from major to critical

comment:4 Changed 9 years ago by stephen

  • Defect Severity set to N/A
  • Owner set to stephen
  • Status changed from new to assigned
  • Sub-Project set to DNS

comment:5 Changed 9 years ago by shane

  • Feature Depending on Ticket set to logging

comment:6 Changed 9 years ago by stephen

  • Owner changed from stephen to UnAssigned
  • Status changed from assigned to reviewing

The aim of this ticket was to assess whether the logging code used in BIND 9 could be used in BIND 10. In brief, I think we could use it and doing so would be faster than writing our own system from scratch.

In more detail:

A comparison between the BIND 9 logging and the BIND 10 logging design has been placed in UsingBind9Logging. This shows that there is a close correspondence between the ideas of the two logging systems, enough for the implementation to be possible without too much work.

To check this, some proof of concept (POC) code was implemented in the branch experiments/stephen-bind9log (Latest commit 1a8cccd0bf7c43b281bd5ed6a7edf9131a2eb536. Note that some of the unit tests fail because of the change in message format; as this was only POC code, the tests were not updated.)

Specific issues and items that came up were:

  • BIND 9 logging is part of libisc and depends fairly heavily on the rest of it. Although it may be possible to extract only the logging code and its dependencies from libisc, in practice the simplest thing to do was to port the whole of libisc across. This proved fairly easy to do in the POC implementation (the code can be found in src/lib/bind9), although some macros that are created during "configure" were hard-coded; the BIND 10 configure script would need modification in a proper implementation.
  • As noted in UsingBind9Logging, the BIND 9 category corresponds to the name of the BIND 10 logger, and the module to the program. In the POC, the program name was taken to be the root logger name. When initializing the logger, one-element "categories" and "modules" arrays were dynamically created and used in setting up the BIND 9 logging for that logger.
  • BIND 10 loggers can be created and destroyed whereas in BIND 9, the logging context for a module is created once during initialization. The POC code stores the BIND 9 context in a static std::map associated with logger name. When a logger is created it checks this map and retrieves the existing context if present.
  • The POC used the current BIND 10 structures to determine whether a message is to be logged, instead of interrogating the BIND 9 data structures. Although done to avoid changing too much code in the POC, on reflection this should be retained; it would minimise the work required to change the underlying implementation at some time in the future.

Some issues that remain to be resolved:

  • libisc is part of BIND 9 at the moment (and stored in CVS). How would BIND 10 keep up to date with changes in it?
  • How would we handle customisations that we may want to do? (e.g. change how the category and module are displayed in the message logged).

Summary

If we decide not to use a third-party package such as log4cxx, then using the BIND 9 logging code in BIND 10 is definitely feasible. I think we should try this before writing a logging system from scratch.

comment:7 Changed 9 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:8 Changed 9 years ago by vorner

  • Owner changed from vorner to stephen

Hello

It is true the logging has quite similar interface and the wrapper in the experiment is quite thin. So yes, it could be used and it is probably better than writing our own.

But there are still some issues, you mentioned some of them (problems with runtime adding and removing of loggers, need have a copy in git and CVS or something), some of you didn't, like the need to pass and update configuration online. And how much is it flexible? If we wanted to have some other fancy logging destination (eg. sending over msgq to a component, printing it on line printer, ...), would it be hard?

Also, I don't like dragging in the whole library just because of logging. In general, I personally prefer using something generally available (eg. external library), because we don't need to maintain it and it can be reused in the system by something else.

On the other hand, is there anything else in the library useful for us?

In short, this is better than writing it ourself, but I like some log4cxx more I guess, even if it has some build problems. Or what was the problem with that one again?

I guess there's no reason to point out issues regarding the experimental code, right?

Anyway, should we close this, or discuss it on some call or something? I'm never sure with tickets that say „investigate“, with the coding ones it's easy, when it's merged, its done.

comment:9 Changed 9 years ago by stephen

But there are still some issues, you mentioned some of them (problems with runtime adding and removing of loggers, need have a copy in git and CVS or something), some of you didn't, like the need to pass and update configuration online.

To address these points:

  • The BIND 9 logging design document suggests that run-time addition and removal of configurations is possible. (Does anyone know for sure?)
  • It might be easiest to treat libisc like third-party software: supply a copy with BIND 10 (in the "ext" directory) from the latest release of BIND 9 and update it only when a new version is released.

And how much is it flexible? If we wanted to have some other fancy logging destination (eg. sending over msgq to a component, printing it on line printer, ...), would it be hard?

I don't think so. And I guess that the BIND 9 team would appreciate us providing extra functionality.

Also, I don't like dragging in the whole library just because of logging. In general, I personally prefer using something generally available (eg. external library), because we don't need to maintain it and it can be reused in the system by something else.

I'm not too keen on that either. However, "libisc" is a single component of BIND 9 and it is simpler to pull the whole lot in than pick and choose the bits we want.

I guess there's no reason to point out issues regarding the experimental code, right?

Right! :-) I just wanted to make sure that it was possible so did only the minimum needed.

Anyway, should we close this, or discuss it on some call or something? I'm never sure with tickets that say „investigate“, with the coding ones it's easy, when it's merged, its done.

The possibility of using log4cplus has come up (https://lists.isc.org/pipermail/bind10-dev/2011-April/002202.html); I'll leave this ticket open as a reminder that we need to make a decision by the next sprint planning meeting.

comment:10 Changed 9 years ago by stephen

  • Resolution set to complete
  • Status changed from reviewing to closed

The topic is on the agenda for the Sprint Planning Session on 2011-05-03.

Note: See TracTickets for help on using tickets.