Bumping up this thread for comments or merging.
On 07/21/2017 04:49 PM, Andjelko Iharos wrote: > On 07/03/2017 01:46 PM, Andjelko Iharos wrote: >> On 07/02/2017 09:52 PM, Willy Tarreau wrote: >>> On Sat, Jul 01, 2017 at 01:37:52AM +0200, Dennis Jacobfeuerborn wrote: > >>>> This could either be introduced only in the current development version >>>> because of the compatibility breakage or a parameter could be introduced >>>> to configure the socket with the new "protocol". If that parameter is >>>> not set then the code could simply not be sent in the response and >>>> messages would be returned just as they are now. >>> >>> This is a good idea. We could for example have a CLI command to enable >>> error code reporting in front of messages. It could become the default >>> in a future version, keeping an option on the stats socket config line >>> to go back to the current output. >> >> Perhaps also add an optional config-file setting to set feedback type on >> startup (that can be overriden through a CLI command)? >> >> Within each use case (different types of automation or no automation) >> one type of output is always likely to be the most desirable. Being able >> to set that with a startup option should be easy for adapting (or not >> adapting) external tools even if the default feedback type changes over >> time. > > After some musing here are two patches implementing this, attached for > comments. > > The first patch mostly just adds the code to support producing severity > output as number or string in cli interactions, as well as configuring > and modifying the behavior. > > The second patch inserts severity information in all places I found > where cli messages are set. In total there are 120, 107 are LOG_ERR, 6 > LOG_INFO, 5 LOG_NOTICE and 2 LOG_WARNING. > > Contributors of cli functionality that produces messages are > particularly welcome to comment on the severity levels I assigned. > > Cheers, > Andjelko >
