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

Create monitoring package

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • 1.10.0
    • None
    • Operator
    • None
    • 5
    • False
    • Hide

      None

      Show
      None
    • False
    • GITOPS Sprint 3244

      Story (Required)

      The goal of this story is to put in a place a complete, atomic package that manages all the monitoring related resources that the operator needs to manage. The package should be complete with all the required functions and unit tests

      Background (Required)

      The monitoring package will be responsible for acting as a monitoring object factory and for providing functions to access the cluster and manage the lifecycle of all monitoring objects touched by the operator. 

      To begin with, the monitoring package is responsible for managing:

      • prometheusRules
      • servicemonitors

      see https://github.com/jaideepr97/argocd-operator-rewrite/tree/main/pkg/monitoring for reference

      Out of scope

      any code changes about how monitoring objects are reconciled in the operator

      Approach (Required)

      • Create a new monitoring package under pkg
      • populate individual files for each managed monitoring resource
      • Each resource in the package must define a ResourceRequest interface
      • package must specify the following functions for each managed resource:
        • create
        • update
        • delete
        • get
        • list
        • request
      • add unit tests to cover all newly added functions

      Dependencies

      none

      Acceptance Criteria (Mandatory)

      • All listed resources have been covered within the package
      • All listed functions have been implemented for each resource
      • Sufficient unit tests to cover all implemented functions

      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
              jrao@redhat.com Jaideep Rao
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: