Set logger verbosity level about controller-runtime

[DirectXMan12]

There should be output at levels 0 and 1 by default (since those actually correspond to Zap levels under the hood). the ZapLogger method just creates a "sane" default configuration for using Zap as the log implementation, so it's possible to set up Zap however you want (see below for an example).

That being said, I'd highly encourage avoiding numeric verbosity levels if you can in favor of filtering on logger prefixes (and potentially actual tags -- I've got some ideas for making that easier) -- it's really easy for numeric verbosity levels to lose their meaning.

Example for setting up Zap in a different configuration:

(Note the message in the zapr documentation: log level 1 corresponds to debug, level 2 corresponds to -2, level 3 corresponds to -3, etc).

import (
    "log"

    "github.com/go-logr/logr"
    "github.com/go-logr/zapr"
    "go.uber.org/zap"
    "go.uber.org/zap/zapcore"
)

func MyZapLogger() (logr.Logger, zap.AtomicLevel) {
    cfg := zap.NewDevelopmentConfig()
    zapLog, err := zapLogCfg.Build(zap.AddCallerSkip(1))
    if err != nil {
        log.Fatalf(err)  // who watches the watchmen?
    }

    // the AtomicLevel can be used to dynamically adjust the logging level
    // there's a helper function (zap.LevelFlag) to add a flag for adjusting it too
    return zapr.NewLogger(zapLog), cfg.Level
}

[DirectXMan12]

That being said, it should be easier to get the "default" config and turn that into a logger in two steps to allow for easy tweaking.

[AMecea]

Thank you @DirectXMan12, I will follow your indications. I think you can close this issue.

FYI: When trying to use other log levels smaller than -1 (e.g. V(2)) with cfg := zap.NewProductionConfig() (with development config works fine) I've got the following panic error. So I will use just the already defined zap log levels to avoid this.

panic: runtime error: index out of range

goroutine 1 [running]:
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore.(*counters).get(0xc0001d2000, 0xc000151cfe, 0xbb762a, 0xc, 0xc000151be0)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore/sampler.go:48 +0x79
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore.(*sampler).Check(0xc00018f560, 0xfe, 0xbee5907d06b7cfd4, 0x2a36d55, 0x11b62a0, 0xbb4baf, 0x7, 0xbb762a, 0xc, 0x0, ...)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore/sampler.go:128 +0x9d
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap.(*Logger).check(0xc0000a91a0, 0x40bffe, 0xbb762a, 0xc, 0xc00010e501)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/logger.go:269 +0x137
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap.(*Logger).Check(0xc0000a91a0, 0xb2a0fe, 0xbb762a, 0xc, 0xfffffffffffffffe)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/logger.go:172 +0x48
github.com/presslabs/mysql-operator/vendor/github.com/go-logr/zapr.(*infoLogger).Info(0xc0000bba40, 0xbb762a, 0xc, 0x0, 0x0, 0x0)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/github.com/go-logr/zapr/zapr.go:69 +0x4e
main.main()
	/home/x/go/src/github.com/presslabs/mysql-operator/cmd/mysql-operator-sidecar/main.go:119 +0x62f

[DirectXMan12]

huh, can you file a bug against https://github.com/go-logr/zapr so that I can take a peek and/or add some docs? Thanks!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[DirectXMan12]

/remove-lifecycle rotten

[DirectXMan12]

/good-first-issue
/kind feature
/priority backlog

[k8s-ci-robot]

@DirectXMan12:
This request has been marked as suitable for new contributors.

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-good-first-issue command.

In response to this:

/good-first-issue
/kind feature
/priority backlog

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.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[DirectXMan12]

closing, we've now got options to configure the underlying zap logger.