[FEATURE]: Add flag for log level configuration

[nantiferov]

Pre-flight checks

• I have searched existing issues and discussions and could not find a duplicate.

Problem / Use case

I noticed that valkey-operator v0.3.0 generates dozens of lines on every reconcile with DEBUG log level.

It happens couple of times per minute and pollutes logs quite a bit. I understand it's early stage of operator development and not a huge issue atm.

Proposed solution

Add new flag to cmd/main.go defining max log level of output. It will be also passed from Helm chart.

This way it will be possible to tune operator logging.

Scope of change

Small (small CRD field or controller behaviour tweak)

API / behaviour impact

• This change is backwards-compatible with existing ValkeyCluster CRs.
• This change introduces a breaking API change in v1alpha1.

Contribution

• I would like to implement this feature myself.
• I would like to help review or test this feature.

Additional context

No response

[jdheyburn]

Makes sense. I wonder what is included in with kubebuilder for managing this.

[nantiferov]

I checked code and seems debug is used now because development set to true in zap.Options in https://github.com/valkey-io/valkey-operator/blob/main/cmd/main.go#L110

// Level configures the verbosity of the logging.
// Defaults to Debug when Development is true and Info otherwise.
// A zap log level should be multiplied by -1 to get the logr verbosity.
// For example, to get logr verbosity of 3, set this field to zapcore.Level(-3).
// See https://pkg.go.dev/github.com/go-logr/zapr for how zap level relates to logr verbosity.
Level zapcore.LevelEnabler

	opts := zap.Options{
		Development:     true,
		StacktraceLevel: zapcore.FatalLevel,
	}

Development itself defines stacktraces configuration:

	// Development configures the logger to use a Zap development config
	// (stacktraces on warnings, no sampling), otherwise a Zap production
	// config will be used (stacktraces on errors, sampling).

[nantiferov]

I think this PR should implement this #324

PTAL and let me know if I missed something. Not sure if tests are required for this.

[bjosv]

I believe we already get some flags to modify the log level (and more) from the controller-runtime (see a reference in the operator-sdk docs).

We get --zap-log-level= and when patching a running operator it seem to set the wanted log-level:

kubectl -n valkey-operator-system patch deployment valkey-operator-controller-manager --type=json \
-p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--zap-log-level=info"}]'

We could just add something like the following to the values.yaml in helm.

manager:
  # Additional command-line arguments for the operator binary
  # Example: set log verbosity
  #   args:
  #     - --zap-log-level=info    # debug, info, error
  args: []

I see that many kubebuilder-based operators use this argument, WDYT?

[nantiferov]

Hmm, I cannot find --zap-log-level=info option in valkey-operator deployment and neither in cmd/main.go.

[nantiferov]

Ah, sorry. Missed that it's patch in your example.
Tested on latest 0.4.0 operator deployment and seems it's working as expected. Thank you 🙂

So just adding this comment to Helm chart should be enough.

[nantiferov]

Opened issue in Helm chart repo instead valkey-io/valkey-helm#229