Allow modifying log verbosity in CDI

[alromeros]

What this PR does / why we need it:

This PR aims to make the debugging process of CDI easier, allowing changes in log verbosity from the CDI config.

It adds a new field in the CDIConfig API to allow specifying a different log verbosity level to re-initialize all loggers. Changes in this field will restart all CDI components to initialize all loggers with the new value.

Special notes for your reviewer:

The new API looks like this:

apiVersion: cdi.kubevirt.io/v1beta1
Kind: CDI
# ...
spec:
  config:
      logVerbosity: 4

I opted for a simpler API compared to the one used in kubevirt. I think the kubevirt API is overkill for CDI, but I can always change it if preferred.

Release note:

Allow modifying log verbosity in CDI

[alromeros]

@akalenyu wondering if it'd be useful to have individual verbosity levels for all components as they have in kubevirt, wdyt? At first glance seems overkill for CDI.

[akalenyu]

@akalenyu wondering if it'd be useful to have individual verbosity levels for all components as they have in kubevirt, wdyt? At first glance seems overkill for CDI.

Yeah, I think we can start off just with the global verbosity value, just have to make sure we're
fine for additions in the future.. @mhenriks WDYT? would a struct with .globalVerbosity be better for that?

[alromeros]

@akalenyu wondering if it'd be useful to have individual verbosity levels for all components as they have in kubevirt, wdyt? At first glance seems overkill for CDI.

Yeah, I think we can start off just with the global verbosity value, just have to make sure we're fine for additions in the future.. @mhenriks WDYT? would a struct with .globalVerbosity be better for that?

Yeah I like the idea of having a struct so it's more maintainable, Let's see what others think.

[mhenriks]

I think this is fine for infra components but what about worker pods?

[awels]

The workloads get their verbosity from the controllers that create them. So the import controller creates pods and grabs the verbosity from the cdi-deployment. For example the import controller https://github.com/kubevirt/containerized-data-importer/blob/main/pkg/controller/import-controller.go#L1191 gets the verbosity from the reconciler field, which is set when the controller is started.

[mhenriks]

/lgtm
/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mhenriks

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mhenriks]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[awels]

We should probably discuss if and how far we want to backport this as it could be really helpful with debugging customer issues.

[alromeros]

@mhenriks @awels are we ok with having a single verbosity value? Or do you prefer to use a struct as proposed by @akalenyu so we can add more fields in the future?
/hold

[awels]

I am fine with a single verbosity value. I am not sure there is much value in a more granular approach.

[alromeros]

/unhold

[awels]

/test pull-containerized-data-importer-e2e-hpp-latest

[awels]

/lgtm