Uploaded image for project: 'OpenShift Monitoring'
  1. OpenShift Monitoring
  2. MON-3168

Add option to specify resource limits for all components

XMLWordPrintable

    • resource limits
    • False
    • None
    • False
    • Not Selected
    • NEW
    • To Do
    • MON-3159Technical Debt
    • NEW
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      With this release, you can now specify resource requests and limits for all monitoring components, including the following:

      * Alertmanager
      * kube-state-metrics
      * node-exporter
      * openshift-state-metrics
      * Prometheus
      * Prometheus Operator and its Admission webhook
      * Telemeter Client
      * Thanos Querier
      * Thanos Ruler

      In previous versions of {product-title}, you could only set options for Prometheus, Alertmanager, Thanos Querier, and Thanos Ruler.
      Show
      With this release, you can now specify resource requests and limits for all monitoring components, including the following: * Alertmanager * kube-state-metrics * node-exporter * openshift-state-metrics * Prometheus * Prometheus Operator and its Admission webhook * Telemeter Client * Thanos Querier * Thanos Ruler In previous versions of {product-title}, you could only set options for Prometheus, Alertmanager, Thanos Querier, and Thanos Ruler.
    • Enhancement

      Epic Goal

      • Users can today specify resource requirements for some of the components:
        • Prometheus (in-cluster and UWM), only for the prometheus container.
        • Alertmanager (in-cluster and UWM), only for the alertmanager container.
        • Thanos Querier, only for the thanos-query container.
        • Thanos Ruler, only for the thanos-ruler container.
      • We should extend that too all containers, that potentially use too many resources.
      • Similar configuration options might be exposed for other components (subject for evaluation)
        • Node exporter
        • Kube state metrics
        • OpenShift state metrics
        • prometheus-adapter
        • prometheus-operator + admission webhook (platform and UWM)
        • telemeter-client

      Why is this important?

      Scenarios

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. …

      Open questions::

      1. …

      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>

          1.
          		 Post-merge Testing Sub-task Closed Undefined Junqi Zhao
          2.
          		 E2E Automation Sub-task Closed Undefined Junqi Zhao
          3.
          		 CI Integration Sub-task Closed Undefined Junqi Zhao

              prasriva@redhat.com Pranshu Srivastava
              jfajersk@redhat.com Jan Fajerski
              Junqi Zhao Junqi Zhao
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: