Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-9712

Observability Currency updates for 2.11

XMLWordPrintable

    • Observability Currency updates for 2.11
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

      • Ensure Observability is up-to-date with upstream components it consumes

      Why is this important?

      • Observability currently consumes a number of upstream components. Ensure that the currency of these components is kept up-to-date in Observability to
        • Keep in sync with upstream so that Stolostron fork is not too far behind in feature/function
        • Components can be upgraded easily in future releases
        • Bug fixes and other performance improvements are delivered with successive Stolostron releases of these upstream components

      Relevant component list:

      • kube-thanos
      •  Observatorium
      •  Observatorium operator
      •  Grafana
      •  Prometheus (*ks)
      •  Prometheus Operator (*ks)
      •  node-exporter
      •  kube-state-metrics

      Scenarios

      1.  

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • Backward compatibility is maintained after upgrade
      • Feature changes, API changes due to version upgrade must be notated via appropriate deprecation statements

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Upgrade Strategy

      The target components can be grouped as below:

      Metrics collection prerequisites

      kube-state-metrics
      node-exporter
      kube-rbac-proxy

      Observatorium/Thanos group

      observatorium
      observatorium-operator
      Thanos
      thanos-receive-controller

      Prometheus and star-ks components

      prometheus
      prometheus-alertmanager
      acm-prometheus-config-reloader
      acm-prometheus-operator

      Grafana and other dependent components

      grafana
      grafana-dashboard-loader (review function to see if any changes needed)

      Open questions::

      1. This needs to be a recurring epic. How do we create a recurring epic?
      2. Should we upgrade with every Stolostron release? or only do updates for alternate releases?
      3. Should we upgrade on a regular cadence independent of Stolostron release cycle of these components (e.g., every 10 weeks)?
      4.  What should be the testing strategy?

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

      ACM Epic Done Checklist

      See presentation and details.

      Update with "Y" if Epic meets the requirement, "N" if it does not,  or "N/A" if not applicable.

      • _ FIPS Readiness
      • _ Works in Disconnected
      • _ Global Proxy Support
      • _ Installable to Infrastructure Nodes
      • _ No impacts to Performance and Scalability
      • _ Backup and Restorable

              rhn-support-cstark Christian Stark
              mzardab@redhat.com Moad Zardab
              Xiang Yin Xiang Yin
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: