ocrd_utils.is_oai_content: downgrade loglevel

[bertsky]

Perhaps we should exhaustively search for all such places...

IMHO core logging should not be gabby by default.

You can of course argue that the user could increase their default logger ocrd* filter levels. But that's already an expert step.

In that light, I really don't understand what motivated ed33ac6 (maybe @kba can elaborate) and recommend reverting (i.e. raising the root and ocrd loggers, used both on the default console and file handler, to INFO again).

[kba]

In that light, I really don't understand what motivated ed33ac6

This was part of a refactoring the logging to make it consistent and easier to debug while developing the network implementation. See #1101, #1109 and #1117 for the discussion.

IMHO core logging should not be gabby by default.

That's also a valid point of view. Behavior can always be overridden, but we must decide on the defaults of course. I am agnostic here, since I always use an ocrd_logging.conf these days, so default behavior is less important to me. I think @MehmedGIT is on "team verbose" - could you live with a default level of INFO?

[MehmedGIT]

IIRC, it was set to DEBUG to allow us get more verbose information when the logging refactoring was on-going and logging was broken.

This was also needed with the ocrd_networking module since the ocrd_logging.conf was not sufficient enough to set all unknown loggers (from 3rd part libraries). At some point, DEBUG was also used to know exactly what gets logged to the separate proccesing job log files for each job since there were inconsistencies.

It can be reverted back to INFO again. Then @joschrew and me could report additionally if there is something still missing or logging acting weird due to that change.

[bertsky]

Thanks!

BTW, can the global log level override embedded into the multi-CLI (-l DEBUG) still be used to get a debug log if needed – even for the servers?