Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-4016

Add support for changing log level of manager

    XMLWordPrintable

Details

    • 3
    • False
    • None
    • False
    • Hide
       With this update, you can configure log levels "debug", "info", "warn", "error", "panic" and "fatal". Default level of output is set to "info". Users can select the appropriate log level by adding environment variable `LOG_LEVEL` in the GitOps subscription's `spec.config.env` field.

       For example:
      ```yaml
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: gitops-operator
        namespace: openshift-gitops-operator
      spec:
        ...
        config:
          env:
          - name: LOG_LEVEL
            value: "error"
      ```
      Show
       With this update, you can configure log levels "debug", "info", "warn", "error", "panic" and "fatal". Default level of output is set to "info". Users can select the appropriate log level by adding environment variable `LOG_LEVEL` in the GitOps subscription's `spec.config.env` field.  For example: ```yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata:   name: gitops-operator   namespace: openshift-gitops-operator spec:   ...   config:     env:     - name: LOG_LEVEL       value: "error" ```
    • GITOPS Sprint 3252

    Description

      Story (Required)

      Background (Required)

       

      _link: https://issues.redhat.com/browse/GITOPS-3946_ 

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      There is a PR merged in Argocd-operator that fixes this issue by adding an env variable `LOG_LEVEL` that can be used to specify the level of logs that user desires. We can cherry-pick the changes required for gitops-operator.

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

      Acceptance Criteria (Mandatory)

      <Describe edge cases to consider when implementing the story and defining tests>

      <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

      Attachments

        Activity

          People

            rh-ee-ansingh Anand Singh
            rh-ee-ansingh Anand Singh
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: