Operator :: Accept LogLevel

[thisthat]

Goal

Update the Helm chart to allow the possibility of configuring the log level.

Technical Details

In #697, we introduced a Helm chart for the operator. Each controller shall have its own category with the value logLevel that defines the verbosity of the controller logger.

Example:

operator:
  metricController:
    logLevel: 10
  evaluationController:
    logLevel: 10

These values will configure the KeptnConfig CRD installed.

DoD

• Adapt the code to use these values.

Reference

• feat: create an helm overlay #697
• https://pkg.go.dev/github.com/go-logr/zapr#section-readme
• Look at the description in Make Image Pull Policy configurable via Helm value #721 for guidance
• Make sure to regenerate helm docs using lifecycle-toolkit/.github/scripts/generate-helm-docs.sh
• Reach out to @mowies or @thisthat for support

[sudiptob2]

Hi I am interested in this issue. I am a beginner in opensource. I have experience in Kubernetes and Helm. I believe I will be able to tackle this issue as the issue as it has been marked as good-first-issue

[sudiptob2]

Hi, @thisthat could you please give me some hints on how to solve this issue? Where can I find the available controllers?

[RealAnna]

Hi, @thisthat could you please give me some hints on how to solve this issue? Where can I find the available controllers?

Hi @sudiptob2 all the operator controllers are in this folder here https://github.com/keptn/lifecycle-toolkit/tree/main/operator/controllers

If you check each has a controller.go file where the struct containing the log is defined, ex. https://github.com/keptn/lifecycle-toolkit/blob/main/operator/controllers/lifecycle/keptnapp/controller.go

the controllers are all initialized in the main https://github.com/keptn/lifecycle-toolkit/blob/main/operator/main.go

To start you could setup all the needed helm values and the ovelray like for the previous pr

[sudiptob2]

needed helm values and the
@RealAnna Thanks much for such a specific description. I am on it 🏃‍♂️

[sudiptob2]

Hi, @RealAnna Thanks for instructing me for solving this ticket. I defined the issue as,

• Define log levels in the values.yaml
• Update overlay with the loglevel values
• Adapt code to use the loglevel values from the env

Initially, I defined the controller's log level in the values.yaml. I found 9 controllers and defined them in the values.yaml as you can see in the draft PR. Looking forward to your comment and any suggestion you have.

Now in the overlay, I have to set up the env vars for log levels. For example,

          env:
            - name: COMMON_COLLECTOR_LOG_LEVEL
              value: "{{ .Values.operator.commonController.logLevel }}"

Also, do you have any suggestion on how I should name the Env Vars?

[RealAnna]

@sudiptob2 that's cool, yes that is the way to go. I would keep the env name as you proposed in the example.

          env:
            - name: COMMON_COLLECTOR_LOG_LEVEL
              value: "{{ .Values.operator.commonController.logLevel }}"

[RealAnna]

make sure to check the debug level available for our logger https://pkg.go.dev/github.com/go-logr/zapr#section-readme

[sudiptob2]

make sure to check the debug level available for our logger https://pkg.go.dev/github.com/go-logr/zapr#section-readme

Thanks much for giving this hint. Working on it.

[sudiptob2]

@RealAnna
Thank you for directing me to the Zapr log-level documentation. After reviewing it, I'm feeling a bit unsure about how to utilize the log levels. I noticed that the debuglevel is represented numerically as-1, and the verbosity increases as we move toward -127.

Based on my understanding, I believe it would be best to leave the log level at its default value of -1 in the values.yaml file. Can you confirm if this is the correct approach?