[squid-dev] RFC: Categorize level-0/1 messages

[Amos Jeffries]

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