On 21/10/21 16:16, Alex Rousskov wrote:
On 10/20/21 3:14 PM, Amos Jeffries wrote:
On 21/10/21 4:22 am, Alex Rousskov wrote:
To facilitate automatic monitoring of Squid cache.logs, I suggest to
adjust Squid code to divide all level-0/1 messages into two major
categories -- "problem messages" and "status messages"[0]:
We already have a published categorization design which (when/if used)
solves the problem(s) you are describing. Unfortunately that design has
not been followed by all authors and conversion of old code to it has
not been done.
Please focus your project on making Squid actually use the system of
debugs line labels. The labels are documented at:
https://wiki.squid-cache.org/SquidFaq/SquidLogs#Squid_Error_Messages
AFAICT, the partial classification in that wiki table is an opinion on
how things could be designed, and that opinion does not reflect Project
consensus.
The wiki was written from observation of how the message labels are/were
being used in the code. As such it reflects the defacto consensus of
everyone ever authoring code that used one of the labels.
NP: The "core team" or "dev team" are not "The Project". There are a
large number of developers contributing to each version of Squid whose
only voice in any of the style/design decisions is the existing Squid code.
FWIW, I cannot use that wiki table for labeling messages, but
I do not want to hijack this RFC thread for that table review.
You our text below contradicts the "cannot" statement by describing how
the two definitions fit together and offer to use the wiki table labels
for problem category.
I assume the below text is your definition of "cannot"? if not them
please explain why not.
Fortunately, there are many similarities between the wiki table and this
RFC that we can and should capitalize on instead:
* While the wiki table is silent about the majority of existing
cache.log messages, most of the messages it is silent about probably
belong to the "status messages" category proposed by this RFC.
Exactly so.
This
assumption gives a usable match between the wiki table and the RFC for
about half of the existing level-0/1 cache.log messages. Great!
* The wiki table talks about FATAL, ERROR, and WARNING messages. These
labels match the RFC "problem messages" category. This match covers all
of the remaining cache.log messages except for 10 debugs() detailed
below. Thus, so far, there is a usable match on nearly all current
level-0/1 messages. Excellent!
Thus my request that you use the wiki definitions to categorize the
unlabeled and fix any detected labeling mistakes.
* The wiki table also uses three "SECURITY ..." labels. The RFC does not
recognize those labels as special. I find their definitions in the wiki
table unusable/impractical, and you naturally think otherwise, but the
situation is not as bad as it may seem at the first glance:
- "SECURITY ERROR" is used once to report a coding _bug_. That single
use case does not match the wiki table SECURITY ERROR description. We
should be able to rephrase that single message so that does it not
contradict the wiki table and the RFC.
- "SECURITY ALERT" is used 6 times. Most or all of those cases are a
poor match for the SECURITY ALERT description in the wiki table IMHO. I
hope we can find a way to rephrase those 6 cases to avoid conflicts.
- "SECURITY NOTICE" is used 3 times. Two of those use cases can be
simply removed by removing the long-deprecated and increasingly poorly
supported SslBump features. I do not see why we should keep the third
message/feature, but if it must be kept, we may be able to rephrase it.
If we cannot reach an agreement regarding these 10 special messages, we
can leave them as is for now, and come back to them when we find a way
to agree on how/whether to assign additional labels to some messages.
AFAICT, they were added as equivalent to ERROR/WARNING in CVE fixes, or
to highlight a known security vulnerability being opened by admin settings.
I am okay with them remaining untouched by a PR submission cleaning
level 0/1 messages. Though they are there to use if any author finds a
message that suitably meets their definition.
Thus, there are no significant conflicts between the RFC and the table!
We strongly disagree how labels should be defined,
Recall that the wiki is describing the observed pattern of label usage
by all Squid contributors. That means any significant conflict is
between your choice of definition and "The Project" as a whole. Minor
conflicts may be just differences in my wording and yours on the
observed pattern.
but I do not think we
have to agree on those details to make progress here.
The options for any author are to comply with the existing
consensus/pattern or to get agreement on changing the definitions.
Options like changing the labeling scheme are off the table because we
already have significant amounts of community using those labels with
third-party tools etc. i.e. the "automatic monitoring" cited as target
use-case for this proposal are already using the wiki labels as their
category types.
We only need to
agree that (those 10 SECURITY messages aside) the RFC-driven message
categorization projects should adjust (the easily adjustable) messages
about Squid problems to use three standard labels: FATAL, ERROR, and
WARNING. Can we do just that and set aside the other disagreements for
another time?
Agreed.
If there are serious disagreements whether a specific debugs() is an
ERROR or WARNING, we can leave those specific messages intact until we
find a way to reach consensus. I hope there will be very few such
messages if we use the three labels from the RFC and do our best to
avoid controversial changes.
You may have misunderstood the intention behind my request.
IMO you should not need a formal definition of "status message" and
"problem message".
All it needs to do is go straight to determine whether the message
meets one of the wiki labels and apply it or the debugs to level2+.
"status" vs "problem messages" are an emergent property of the correctly
used labels.
What we do not have in that design is clarity on which labels are shown
at what level.
In hope to make progress, I strongly suggest to _ignore_ the difference
between level 0 and level 1 for now. We are just too far apart on that
topic to reach consensus AFAICT. The vast majority of messages that
RFC-driven projects should touch (and, if really needed, _all_ such
messages!) can be left at their current level, avoiding this problem.
Okay. IIRC there are a large number that will need to change verbosity,
but fine to do that later.
Amos
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
