[controller-runtime] log.SetLogger(...) was never called; logs will not be displayed.

[porridge]

What happened:

Noticed this warning in a test run:

[controller-runtime] log.SetLogger(...) was never called; logs will not be displayed.
Detected at:
	>  goroutine 7 [running]:
	>  runtime/debug.Stack()
	>  	/usr/local/go/src/runtime/debug/stack.go:24 +0x65
	>  sigs.k8s.io/controller-runtime/pkg/log.eventuallyFulfillRoot()
	>  	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.3/pkg/log/log.go:60 +0xcd
	>  sigs.k8s.io/controller-runtime/pkg/log.(*delegatingLogSink).WithName(0xc000041180, {0x18e3701, 0x14})
	>  	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.3/pkg/log/deleg.go:147 +0x4c
	>  github.com/go-logr/logr.Logger.WithName({{0x1b57f18, 0xc000041180}, 0x0}, {0x18e3701?, 0x0?})
	>  	/go/pkg/mod/github.com/go-logr/logr@v1.2.4/logr.go:336 +0x46
	>  sigs.k8s.io/controller-runtime/pkg/client.newClient(0x13b1afa?, {0x0, 0xc000247960, {0x1b595f0, 0xc00051da40}, 0x0, {0x0, 0x0}, 0x0})
	>  	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.3/pkg/client/client.go:122 +0xff
	>  sigs.k8s.io/controller-runtime/pkg/client.New(0xc000474240?, {0x0, 0xc000247960, {0x1b595f0, 0xc00051da40}, 0x0, {0x0, 0x0}, 0x0})
	>  	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.3/pkg/client/client.go:103 +0x85
	>  github.com/kudobuilder/kuttl/pkg/test/utils.NewRetryClient(0xc00012cc00?, {0x0, 0xc000247960, {0x1b595f0, 0xc00051da40}, 0x0, {0x0, 0x0}, 0x0})
	>  	/go/pkg/mod/github.com/kudobuilder/kuttl@v0.15.1-0.20240201073944-c735bec25959/pkg/test/utils/kubernetes.go:177 +0x125
	>  github.com/kudobuilder/kuttl/pkg/test.(*Harness).Client(0xc00012cc00, 0x0?)
	>  	/go/pkg/mod/github.com/kudobuilder/kuttl@v0.15.1-0.20240201073944-c735bec25959/pkg/test/harness.go:323 +0x19f
	>  github.com/kudobuilder/kuttl/pkg/test.(*Step).Create(0xc0001475f0, 0xc00058c4e0, {0xc0007cc340, 0x1b})
	>  	/go/pkg/mod/github.com/kudobuilder/kuttl@v0.15.1-0.20240201073944-c735bec25959/pkg/test/step.go:177 +0x6f
	>  github.com/kudobuilder/kuttl/pkg/test.(*Step).Run(0xc0001475f0, 0xc00062d5f0?, {0xc0007cc340, 0x1b})
	>  	/go/pkg/mod/github.com/kudobuilder/kuttl@v0.15.1-0.20240201073944-c735bec25959/pkg/test/step.go:457 +0x265
	>  github.com/kudobuilder/kuttl/pkg/test.(*Case).Run(0xc00052d4a0, 0xc00058c4e0, 0xc0003fc8c0)
	>  	/go/pkg/mod/github.com/kudobuilder/kuttl@v0.15.1-0.20240201073944-c735bec25959/pkg/test/case.go:362 +0x74e
	>  github.com/kudobuilder/kuttl/pkg/test.(*Harness).RunTests.func1.1(0xc00058c4e0)
	>  	/go/pkg/mod/github.com/kudobuilder/kuttl@v0.15.1-0.20240201073944-c735bec25959/pkg/test/harness.go:401 +0x1ea
	>  testing.tRunner(0xc00058c4e0, 0xc0001a6b10)
	>  	/usr/local/go/src/testing/testing.go:1576 +0x10b
	>  created by testing.(*T).Run
	>  	/usr/local/go/src/testing/testing.go:1629 +0x3ea

What you expected to happen:

No warning :-)

How to reproduce it (as minimally and precisely as possible):

Not sure...

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• KUTTL version (use kubectl kuttl version): v0.15.1-0.20240201073944-c735bec25959
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[chenmj11]

I also encountered this problem，this warning will be triggered when running a lot of harnesses

[porridge]

This thread might (or not) have some hints on how to approach this.

[kumar-mallikarjuna]

controller-runtime expects this struct for logging. We can likely use logr.New(...) for this. But the existing Logger interface would need to be made compatible with logr.LogSink.

https://github.com/kudobuilder/kuttl/blob/6f041b7d2f74e065bd7b96c6305cc224ff955181/pkg/test/utils/logger.go#L11C1-L17C2

More effort but does it make sense to migrate to zap?

[porridge]

the existing Logger interface would need to be made compatible with logr.LogSink.

This should be possible without touching the existing methods, right?

What would be the benefits of using zap? Sorry, I never quite figured out the logging landscape of kubernetes :-)

[kumar-mallikarjuna]

the existing Logger interface would need to be made compatible with logr.LogSink.

This should be possible without touching the existing methods, right?

Not really, since the interface signatures must match.

What would be the benefits of using zap? Sorry, I never quite figured out the logging landscape of kubernetes :-)

zap is pretty much now the standard with K8s Operators now since it works well with controller-runtime. It's also easy to integrate with cobra and has neat structured logs.

[porridge]

the existing Logger interface would need to be made compatible with logr.LogSink.

This should be possible without touching the existing methods, right?

Not really, since the interface signatures must match.

I don't see any overlapping methods, am I missing something?

What would be the benefits of using zap? Sorry, I never quite figured out the logging landscape of kubernetes :-)

zap is pretty much now the standard with K8s Operators now since it works well with controller-runtime. It's also easy to integrate with cobra and has neat structured logs.

Right. However what matters for kuttl is whether it can act as a proxy to testing.T.Log?

[siredmar]

I am also facing this topic but i only have one harness.