log/zap: Allow configuring formatter independently of debug option

[alvaroaleman]

Right now, the formatter/encoder of the log/zap package is inferred from the debug option, if its enabled a console encoder is used, otherwise a json encoder. This does not always make sense, e.G. sometimes debug log may help in production, but that should not result in unstructured logging.

It would be awesome, if another option was added to RawLoggerTo to make this configurable. Alternatively, we could use a different type for opts that contains an option for the encoder.

[DirectXMan12]

/kind feature
/priority backlog
/help-wanted

[DirectXMan12]

/help

[k8s-ci-robot]

@DirectXMan12:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[hpandeycodeit]

@alvaroaleman @DirectXMan12 made some changes to make this configurable. #467 Still WIP as I need to modify the LoggerTo from other places as well if we are looking to change it dynamically.

One question here, how are we deciding when to use console encoder and when not?

[DirectXMan12]

By default, it was debug vs non-debug, but I think we need to start considering how we want to expose these options.

[hpandeycodeit]

@DirectXMan12 can't we use existing development flag to use this option in production as well?

controller-runtime/pkg/log/zap/zap.go

Lines 33 to 35 in 71cdf35

	// If development is true, a Zap development config will be used
	// (stacktraces on warnings, no sampling), otherwise a Zap production
	// config will be used (stacktraces on errors, sampling).

[DirectXMan12]

The development flag control also controls output format (human-readable vs json), so we need more granular options.

[DirectXMan12]

Perhaps we should adopt the "functional options" style here too.