chore(monitoring): remove dead Prometheus rule ConfigMaps - #2092
chore(monitoring): remove dead Prometheus rule ConfigMaps#2092milandufek wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
Included review availability: 2 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. 📝 WalkthroughWalkthroughThe Helm chart version changed from ChangesMonitoring chart update
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This PR removes unused Prometheus rule ConfigMap rendering without changing the active alerting configuration, so no actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
|
":exclamation: THIS PULL REQUEST WILL NEED TO BE DELIVERED MANUALLY ❗
|
|
":exclamation: THIS PULL REQUEST WILL NEED TO BE DELIVERED MANUALLY ❗
|
These ConfigMaps are not read by anything. The last Prometheus able to load ConfigMap-based rules was deleted in 2023 (INFRA-2151). Alerting for this app is evaluated centrally by the Mimir ruler from PrometheusRule CRs in k8s-infra crs/kustomizations/mimir-rules-global/bear/. JIRA: GRIF-518 risk: low
450cf5d to
655fa5e
Compare
|
":exclamation: THIS PULL REQUEST WILL NEED TO BE DELIVERED MANUALLY ❗
|
|
":exclamation: THIS PULL REQUEST WILL NEED TO BE DELIVERED MANUALLY ❗
|
create-staging-pr and create-manual-merge-prod-pr both depend only on
build-helmreleases, so they run concurrently, and both derived
branch_name="${repo_name}/${GITHUB_SHA::8}" -- the is_staging branch and
the else branch of prepare-pr-metadata were identical. Both jobs then
raced to push the same ref into gitops-deployments and the loser failed
with "cannot lock ref ...: reference already exists", taking the gate
with it.
This only fires when a helm chart changes: with charts == '[]',
helm-charts-build skips, build-helmreleases skips, and both PR jobs skip
on build-helmreleases.result == 'success'. The last change under
k8s/charts/ landed in 2021, four years before this pipeline existed, so
the pair had never both run until PR gooddata#2092 bumped lcm-bricks to 2.0.9 and
the gate failed twice in the merge queue.
Suffix the manual-merge prod branch with _prod, following the convention
the auto-merge variant already uses (_${cluster}_automerge), and say
"for all production clusters" in the commit message and PR title so the
staging and prod PRs are distinguishable. No consumer matches on the
title: revert-staging-pr keys off commit_hash and create-pr-comment off
pr_url.
JIRA: GRIF-518
2 participants
Closes work for GRIF-518.
These
monitoring-rules.yaml/alertingRules.yamlConfigMaps are not read by anything:PrometheusRuleCRD. The kube-prometheus-stack ink8s-infrahas noruleFiles, noadditionalRulesConfigMapsand no rules sidecar, and Prometheus Operator never reads arbitrary ConfigMaps.configmap-reload+/etc/prometheus-rules) was deleted back in 2023 by INFRA-2151.monitoring-namespace PrometheusRules. Nothing from the app namespaces, nothing ConfigMap-sourced.Alerting for these apps is evaluated centrally by the Mimir ruler from
k8s-infra/crs/kustomizations/mimir-rules-global/bear/(thegeneric-<team>-rules.yamlfiles plus the app-specific ones).Removed
k8s/charts/lcm-bricks/templates/prometheus/alertingRules.yamlOther changes
k8s/charts/lcm-bricks/Chart.yamlChart versions are bumped so the CD pipeline accepts the rebuild. Values keys that existed only to feed the rules are dropped;
clusterIdis kept wherever another template still uses it.No alerting change.
k8s-infrais untouched, so the ruler's rule set is identical before and after.🤖 Generated with Claude Code
Summary by CodeRabbit
Chores
Monitoring