Is simplestreams spam worth having in the Log

[Ian Booth]

TL;DR:

A lot of the spam is necessary to diagnose when simplestreams look up fails, or
you get the wrong tools. In such cases, it's extremely useful to see where the
search path has looked. This was especially the case in the early days when
published tools and associated metadata sometimes were wrong, or signed json
metadata wasn't always there etc. That was also a time before we had the various
validate utilities which could be used to show from where tools would be selected.

Now that simplestreams issues are the exception rather than the norm, and we
have configurable logging (without which we could not get suitable debug info),
it is a fine time to reduce the logging level to trace.

On 01/04/15 20:47, John Meinel wrote:
> I've been noticing lately that everytime a test fails it ends up having a
> *lot* of lines about failing to find simplestreams headers. (this last test
> failure had about 200 long lines of that, and only 6 lines of actual
> failure message that was useful).
> 
> Now I think there are a few things to look at here:
> 
> 1) The lines about "looking for any" double up and occur 9 times. Why are
> we repeating the search for tools 9 times in "TestUpgradeCharmDir"? maybe
> its genuine, but it sure feels like we're doing work over and over again
> that could be done once.
> 
> 2) We still default to reporting every failed index.json lookup, and *not*
> reporting the one that succeeded. Now these are at DEBUG level, but I have
> the feeling their utility is low enough that we should actually switch them
> to TRACE and *start* logging the one we successfully found at DEBUG level.
> 
> Thoughts?
> 
> John
> =:->
> 
> 
>