Owner: Architect:

Kartikey Mamgain

Story (Required)

As an OpenShift Helm developer, I will like to know how many OpenShift Deployment resources are created via helm chart so that I can count Deployments in our fleet that come from helm.

Background (Required)

As a result of investigation from https://issues.redhat.com/browse/HELM-470, we have come to the conclusion that after the monitoring team can configure the kube deployment labels to make use of label_app_kubernetes_io_managed_by wh have to come up with a recording rule that can be sent to telemetry.

The recording rule is evaluated by prometheus and produces the metric at regular intervals (30s). The telemeter-client will pull the recorded metric and send it to Telemetery.

Glossary

<List of new terms and definition used in this story>

Out of scope

Dashboard and insights operator changes.

In Scope

Cluster Monitoring Operator Rule addition

Approach(Required)

We need to come up with a recording rule to that would count all kube_deployment_labels{label_app_kubernetes_io_managed_by="Helm"} series and the count would be forwarded to Telemetry. The recording rule has to be added to https://github.com/openshift/cluster-monitoring-operator/blob/5db08501f0d6e4e333fc[…]cb/manifests/0000_50_cluster-monitoring-operator_04-config.yaml . The rule will then be  evaluated by prometheus and produces the metric at regular intervals (30s). The telemeter-client will pull the recorded metric and send it to Telemetery. We can look at https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/ to learn more about recording rules.

Demo requirements(Required)

Not applicable

Dependencies

This story does depend upon the monitoring team to configure kube_deployment_labels to make use of  label_app_kubernetes_io_managed_by.

Edge Case

None

Acceptance Criteria

The changes to cluster monitoring operator should be merged.

Wiki Updates

Development:

QE:
Documentation: Yes/No (needs-docs|upstream-docs / no-doc)

Upstream: <Inputs/Requirement details: Concept/Procedure>/ Not
Applicable

Downstream: <Inputs/Requirement details: Concept/Procedure>/ Not
Applicable

Release Notes Type: <New Feature/Enhancement/Known Issue/Bug
fix/Breaking change/Deprecated Functionality/Technology Preview>

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

v

Legend

Unknown

Verified

Unsatisfied