On 2014-02-13 10:36, Alex Rousskov wrote:
On 02/11/2014 04:49 AM, Kinkie wrote:During recent discussion on IRC it was found out that there are not that many big patches queued for landing to trunk; it may be a good moment to rework more aggressively at least part of the debugs() statements.I would like us to get a consensus on this,If you are asking about specific API/design changes rather than just thefact that now is a good time to do them, then I suggest that we attack the problem simultaneously from several different angles: 1. "Admin messages" or "default logging" (admins need this): 1a. What kind of info should be logged to syslog by default.
- None? Busy systems get enough garbage in syslog to require specialized log tracking tools by the admin. Adding to that volume by default is probably a bad idea.
- perhapse DBG_CRITICAL if we actually want to fix the wet-ware bug some admin have of only checking syslog for errors.
1b. What kind of info should be logged to cache.log by default.
see debug_options config directive.Or are you suggesting a different model for message filtering is required?
1c. How to allow admins to selectively control syslog and
cache.log messages when Squid defaults do not work well.
See squid -l and -d command line options.
1d. How to make admin message text uniform and stable,
to allow for better automation and documentation.
1e. How to document admin messages.
Wiki and in the message itself. This is already in the guidelines and TODO task list. People are just not doing the wiki part for new CRITICAL/IMPORTANT messages.
So the real 1d-e question is how to improve the requirements to make better documentation coverage happen?
2. "Debugging" (support folks and developers need this): 2a. How to improve selective control of debugging volume and scope.
see 1d.
2b. How to enable/disable debugging based on rare condition(s). 2c. How to fully debug specific transactions or events.
This is good but can/should be a stand-alone project I think. It does not need to affect every debugs() line in Squid, whereas the other items here may require such.
2d. How to decrease noise and increase usefulness of debugging logs.
Yes. Agreement on a definition for the use of debug levels 2-8 would be a great start.
3. Writing debugging code (developers need this): 3a. How to make it easier to write good debugging statements. 3b. How to verify that a debugs() call complies with the new rules. 3c. How to keep default logging overheads low while addressing #1.3d. How to lower performance overheads of debugging while addressing #2.There is significant overlap within each section and even between the three sections, of course. That is one of the reasons why I think a comprehensive solution is needed here as opposed to small incremental changes. Another reason to push for a comprehensive solution is theamount of widespread code changes most significant improvements ought totrigger.I am sure all of us have specific suggestions/ideas for at least some of the above areas, but I wanted to propose the above skeleton framework tobetter structure the initial debate. Once we settle on the overall goals/scope/structure of this project, we should probably document our agreement on the wiki and start accumulating specific suggestions/ideas there.
I get the opposite conclusion out of your framework. The sheer size of a "comprehensive" project involving debug texts is effectively a full re-write of the Squid codebase in itself (almost every other line touched). Looking at it sideways this is effectively a fork unless it is done directly in trunk. I don't think we really want or need to fork Squid over this.
We know that there are some specific actions that can be taken (ie removing HERE macro) which will greatly improve debug verbosity in both log and sources. Now seems a good time (the best?) to take those steps in trunk with minimal annoyance from touching so much code.
and define some subtrees where work is being done and which should thus not be touched now because they're being worked on (e.g. the parser-ng work)The only large pending Factory patch that I am aware of is ftp-gw. I am pretty sure that by the time debug-ng design is agreed upon and implemented, the native FTP code will be submitted for review and, hopefully, committed -- we just need to finish reshuffling the files/class as agreed previously on squid-dev...
parser-ng will be fine. Code shuffling in that project is relatively small and debugs() conflicts are not an issue for brand new or dropped code.
The connection-manager branch is affected a large amount. However, at present I can cope with conflicts there fairly easily provided they are limited to polishing existing debugs() lines. Or if Alex and I can agree on finalizing the changes soonish, it may become a non-issue.
Amos
