logging level all everything

[Keith]

On 11/09/18 05:41, Harald Welte wrote:
> Hi Neels,
>
> On Mon, Sep 10, 2018 at 11:26:46PM +0200, Neels Hofmeyr wrote:
>
>> So, I want to make 'logging level all' manipulate each individual category
>> once-off, I want to completely deprecate the 'everything' keyword, and drop the
>> "global clamp" feature entirely.
>>
>> Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)' and
>> 'no logging level force-all' to switch it off. That would be exactly the old
>> clamping feature just with less confusing names.
Well, I was in favour of the "clamp" originally, and I was using it a
lot, hence my manual patching for a while of libosmocore to restore
"everything" as "clamp-remover".

I use it less now, if ever I do do something like logging level all
debug, I know I have to exit the vty and start again to remove the clamp.
 
>>
>>
>> The only thing that makes me write here is that I'm only 90% sure on changing
>> the meaning of an existing command, of 'logging level all'. If there is no
>> negative feedback on this here, that would bring me to 100%.
> In terms of semantics, old notes/documentation, etc. I would suggest to simply
> deprecate "all" and introduce a new command instead.  If the global clamping
> is removed, then "logging level all debug" could simply become a no-op, so if people
> type it in because they are used to it, or have it in some old configs, no
> harm is done.  And if they use "logging level all notice" then they should get
> a non-fatal warning/notice message that this command is no longer supported.

You /could/ just reinstate the "all everything" as clamp remover.

Note that doing "write" in the vty still writes a "logging level all
everything" line to the config, causing a warning on startup:
 % Ignoring deprecated logging level everything

Then leave logging level all notice meaning "clamp to notice" (as it
always was).

I honestly never found this difficult to understand once I understood
how it worked, so I'd suggest documenting "all" as a "clamp" and
suggesting prefer the use of "set-all"
>
> So in short: I suggest to not overload existing keywords, but introducing new ones
> with well-defined/documented meaning.
>
Then add logging level set-all [level]?
set-all makes most sense to me out of the suggestions, for a temporary

But again... I really don't mind.. I don't want to wreck your head,
Neels, in making decisions. Deprecate 'all' if you want.
As I said before I just use expect scripts as shell functions to setup
different logging scenarios:

rhizomatica at rccnII:~$ type nitb_cc
nitb_cc is a function
nitb_cc ()
{
    /usr/bin/expect -c 'spawn telnet localhost 4242;send "enable\r";send
"logging enable\r";send "logging print category 1\r";send "logging level
smpp fatal\r"; send "logging level mncc debug\r"; send "logging level cc
debug\r"; send "logging filter all 1\r"; interact'
}



I think this is easier that trying to put that functionality into
osmocore itself.. which would be something like

logging level foo bar.. [..repeat according to preferences..]
then
logging scenario save mylogging

logging scenario load mylogging

One has more urgent things to do.. right?

k/