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

Operator logs should have human readable timestamps

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • 1.10.0
    • 1.8.2
    • Operator
    • 5
    • False
    • None
    • False
    • Hide
      With this update, OpenShift GitOps Operator logs will now have human-readable timestamps. Previously timestamps had been displayed with the Unix epoch timestamp, but have now been changed to RFC3339 format (ex: 2023-06-27T07:12:48-04:00) for easier readability.
      Show
      With this update, OpenShift GitOps Operator logs will now have human-readable timestamps. Previously timestamps had been displayed with the Unix epoch timestamp, but have now been changed to RFC3339 format (ex: 2023-06-27T07:12:48-04:00) for easier readability.
    • GITOPS Sprint 242

      Story (Required)

      As the administrator of a cluster, I want human readable timestamps in the log files of gitops-operator to support my troubleshooting efforts.

      Background (Required)

      Our operator produces log files with timestamps that are in a format not suitable for human consumption, i.e.
      1.6836460073031614e+09

      Out of scope

      Refactor logging __ 

      Approach (Required)

      Change the default format for timestamps when logging.

      Dependencies

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

      Acceptance Criteria (Mandatory)

      • Timestamps in operator log files are being produced in a format also used across other Kubernetes components and are human-readable, i.e. 2020-02-01T09:44:40.954641934Z

      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

              yicai@redhat.com Yi Cai
              jfischer@redhat.com Jann Fischer
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: