Use of log pkg and Fatal in Controller

[embano1]

Since the SDK is used as a library and dependency for building connectors, it should leave logging and error handling in the responsibility of the user of the SDK, e.g.

• make logger configurable (currently hardcoded to "log")
• avoid log.Fatal calls, e.g. here
• make extensive use of returning errors to the caller, following the widely used go conventions of error handling in main()

[alexellis]

Hi Michael,

Thanks for these suggestions.

I'm ok with using log.Fatal in the place of log + panic.

Generally in the OpenFaaS codebase we don't have configurable logging or log-levels.

Which parts of logging would we disable? If you have some specific suggestions we should look at a flag to control that.

I see your points on improving the library - the SDK is meant to be single purposed and used in connectors like the ones we already have. (We should be able to defend all the logging statements or remove them.)

Alex

[embano1]

Thx Alex for your feedback,

Speaking of a SDK, we should be not opinionated about the way we fatal/panic or log. I think it would improve the SDK if logging is configurable and we avoid fatal/panic as much as possible as this gives the user full control of the behavior of the system.

Proposal: add an interface type Logger interface with a minimum set of Print statements (e.g. Printf()). Accept a logger when creating the controller, if logger is nil, default to log.Logger. In case of error, return this to the caller instead of fatal/panic.

Related reading: https://dave.cheney.net/2015/11/05/lets-talk-about-logging