Hi all,
for logging changes, I would welcome a comprehensive approach and maybe add an
all new set of logging commands, to not confuse with the current logging
behavior; keep and deprecate the old ones for users that were fine with those.
(I was the one responsible for the death of 'logging level all everything', and
I've stumped at least one user who now keeps patching it back in manually;
let's not repeat that.)
Maybe we can come up with more meaningful wording that more accurately indicate
what is happening? But if the current command set suffices without confusion,
we can also keep that, and maybe resurrect the 'logging level all everything'??
Here are the handles / use cases that come up -- I've embedded implementation
choices and command names in this proposal, but it's intended as a blueprint to
incorporate everyone else's bikesheds:
A) The hardcoded logging landscape on program startup without config.
(Maybe this isn't all that important, including it nevertheless.)
1) a command to reset all to hardcoded defaults?
B) A "normal" logging behavior configured by the user. We need:
1) a command to set all categories at once
2) a command to tweak individual categories
C) Temporarily reducing the logging on all categories: silence the log.
Even though a category is "normally" set to INFO, after this command it can
be forced down to only log e.g. NOTICE. But if a category is already on
ERROR, leave it down there and do not lift it up to NOTICE.
1) a command to temporarily reduce all categories.
2) a command to temporarily reduce individual categories.
D) Temporarily increasing the logging on all categories: show everything.
Even though a category is "normally" set to ERROR, after this command it
can be forced up to e.g. INFO. But if a category is already up at DEBUG,
don't reduce it to NOTICE.
1) a command to temporarily increase all categories.
2) a command to temporarily increase individual categories.
3) we need to decide whether temporarily increasing is stronger/weaker than
temporarily reducing. Depending on the implementation, it could also be
"last one wins" (which IMHO would be best).
T) Maybe we also want to unconditionally set temporary levels, whether they
increase or reduce.
E) Remove temporary logging to go back to the "normal" logging landscape.
1) a command to put everything back to "normal",
2) a command to put individual categories back to "normal",
3) a separate command to only remove temporary reduction, i.e lift the
temporary changes only if they cause less logging than normal,
4) a separate command to only remove temporary verbosity, i.e. only lift the
temporary changes if they cause more logging than normal.
F) Set a specific log context, and silence all messages (regardless of their
logging category setting) unless they match the context filter:
logging filter imsi 123456789123456
Though this feature has probably never been properly implemented through
all code paths, it is potentially very powerful for live debugging.
Especially with the new FSMs around everywhere, there is a good chance that
we can fairly easily improve on the current 'logging filter foo'
experience. During congress, I really yearned for this to work well.
0) In the current implementation, on each individual log message, this
decides whether the context matches, and if not, the message is
discarded.
1) Instead of discarding, we may want a level to reduce to.
2) Or maybe we want to leave the logging landscape unchanged, but lift the
level for all logs that match the set context?
3) disable individual filters
4) disable all filters. This is currently 'logging filter all 1' but that is
confusing, we could use a meaningful synonym, and separate from filters.
G) toggle all logging in the telnet vty
1) silence logging (currently 'logging filter all 0', confusing)
2) continue logging (currently 'logging filter all 1', confusing)
A bit of a meaningless image of different logging layers:
level
^
Hardcoded defaults.. | ... - ====== =....
Normal logging landscape== | == .== ... ==... --
Temporary levels-- | -- =.... ...== - =
| = -- ---- -===
|________________________> categories
Same image with actual current logging overlayed:
level
^
| ... # =###== =....
| == .== ... ==... ##
Resulting levels ## | ## #.... ...## # =
| # ## #### #=#=
|________________________> categories
- the hardcoded defaults are immutable.
- the normal landscape can be freely chosen.
- Some categories may have temporary tweaks. Where there are temporary
tweaks, they take precedence as-is. The vty command ("make stronger" or
"make weaker") decided whether to put a temporary level in place or not.
Can you guys explain the current patch proposals in terms of above features?
(like, use the capital letters A-G for reference)
Feel free to change this vty transcript proposal i've tossed up as I went:
! A.1) hardcoded defaults
logging hard-reset rsl,chan,msc
logging hard-reset
! B) set normal categories
! B.1) all
logging set notice all
! B.2) individual
logging set notice rsl,chan,msc
! C) Temporarily reducing
! C.1) all
logging reduce notice all
! C.2) individual
logging reduce error l1p,nm,cc
! D) Temporarily increasing
! D.1) all
logging increase info all
! D.2) individual
logging increase debug mm,rr
! D.3) last one wins
logging reduce error l1p,mm,rr
logging increase debug mm,rr
logging reduce notice rr
! result: l1p=error mm=debug rr=notice
! T) set temporary level unconditionally
logging set-temp error all
logging set-temp error mm,rr
! logging (recrease|induce) ;)
! E.3) remove temporary verbosity
no logging reduce nm,cc
no logging reduce all
! E.4) remove temporary silencing
no logging increase nm,cc
no logging increase all
! E.2) snap back to normal levels
logging reset rsl,nm,rr
! E.1) ...for all categories
logging reset all
! F.0) context filter
logging filter imsi 123456789123456
! F.1) choose context filter behavior
logging filter-reduce error
logging filter-discard
! F.2)
logging filter-increase debug
! F.3) disable filter
no logging filter imsi
! F.4)
no logging filter
! G.1)
logging [on]
logging 1
! G.2)
no logging
logging 0
Using a .TEXT argument, we could easily allow a space separator for category
lists, as in "l1p mm cc". (nice would be to invent a VTY argument type that
allows any number of the same kind, so far we have weird constructs like seen
in bsc_vty.c, cfg_bts_codec0_cmd thru cfg_bts_codec4_cmd each with a different
nr of same argument)
A test program should define logging categories and a context filter, issue
each of above commands and then log once all across each level and category to
see what logging we still see.
As a final step, we should figure out how the current logging commands match
these features, and make them still do the things they always did as best as
makes sense.
What do you guys think?
About bikesheds: if we can't agree, we could put out a patch contest, where
everyone that cares implements a proposal, and we vote in the end. I hope we
don't waste time by deadlocking in the end ;)
~N