On 07/02/2017 09:52 PM, Willy Tarreau wrote: > Hi Dennis, > > On Sat, Jul 01, 2017 at 01:37:52AM +0200, Dennis Jacobfeuerborn wrote: >> I had to deal with this issue recently as well but I'd rather like to >> see a more explicit and well defined response in all cases rather than >> the workaround proposed above. >> Its not clear why a warning should automatically mean the command was >> unsuccessful and identifying a specific error still requires string >> matches which breaks all clients the moment the wording is changed or a >> typo is fixed. >> >> I'd rather see something along the lines of error codes i.e. 0 for "Ok" >> and anything else for specific errors followed by the message e.g.: >> >> 0:Ok >> 1:No such backend >> 2:No such server in backend >> etc. >> >> This would allow tools working with the socket to always get consistent >> responses and enable them to only parse the response code to identify >> the response regardless of the message. > > This would do the opposite and force all tools to be constantly updated > to learn new codes. Even worse, you'd end up with multiple parallel > registries because most of the time contributed patches have been used > for some time internally, and multiple commands would end up using the > same status codes.
I'm also not fond of the idea of an ever increasing number of status codes and trying to keep them organized, but possibly this is something that cannot be avoided in the future. The severity levels should be well defined and unambiguous in providing ok/not ok information with this: - no severity, DEBUG, INFO, NOTICE : all ok - everything else : not all ok I want to believe that as soon as any of the "not all ok" feedback levels is encountered most external tools will attempt revertion or recovery, but that's why user oppinion on this is so valuable. As long as it's documented that no severity means "all ok", maybe that could be acceptable? We have one cleartext channel we're trying to send both data and informational messages through, and I think severity information shouldn't be present in data output (i.e. show stat) As far as a particular reason what specifically is not ok, status codes would make that clear to parse out, but I suspect that even then some further querying of the stats socket could be required to figure out further actions. There may be more than one problem with an issued command, so we might need to either combine multiple status codes or return multiples. In the end I'm not yet convinced the usefulness outweighs the complexity, but it would certainly be more precise. > > We could use a number of the severity instead of using a word, but in > general it seems important to me that the codification is made once for > all so that tools don't have to be modified in the future. If we go the route of adding CLI commands to modify returned feedback then we can allow either. While single-digit severities are marginally easier to parse, words are easier for humans so both can be useful. > > We've already had some demands to log cli actions, and I tend to think > that using syslog-compatible levels could make this more generic for > all current and future contributions. Should we then plan to output both severity level and a status code, or have all permutations configurable? > >> 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. Cheers, Andjelko
