🏁 Script executed:

#!/bin/bash
# First, find and read the helmrelease file
find . -name helmrelease.yaml | grep "kube-prometheus-stack"

Repository: jlengelbrecht/prox-ops

Length of output: 140

🏁 Script executed:

#!/bin/bash
# Read the full helmrelease.yaml file to understand the values configuration
cat -n kubernetes/apps/observability/kube-prometheus-stack/app/helmrelease.yaml | head -200

Repository: jlengelbrecht/prox-ops

Length of output: 6918

🏁 Script executed:

#!/bin/bash
# Check if the HelmRepository exists
rg -n "prometheus-community" kubernetes/apps/observability/ -A 2 -B 2 | head -50

Repository: jlengelbrecht/prox-ops

Length of output: 1756

🏁 Script executed:

#!/bin/bash
# Search for any deprecated values mentioned in the review (forceDeployDatasources, defaultDashboardsEnabled, serviceMonitorSelectorNilUsesHelmValues)
rg -n "forceDeployDatasources|defaultDashboardsEnabled|serviceMonitorSelectorNilUsesHelmValues" kubernetes/apps/observability/kube-prometheus-stack/

Repository: jlengelbrecht/prox-ops

Length of output: 422

🌐 Web query:

kube-prometheus-stack 81.0.0 breaking changes release notes

💡 Result:

kube-prometheus-stack 81.0.0 — breaking / upgrade-impacting changes

• Major chart bump is driven by Prometheus Operator upgrade to v0.88.0. (newreleases.io)
  Practical implication: expect CRD/schema and admission-webhook validation changes consistent with Prometheus Operator v0.88.0.

• Prometheus Operator v0.88.0 notable “CHANGE” items (most likely to bite during upgrades):

  • Uses narrower selectors for StatefulSet informers in the Alertmanager and ThanosRuler controllers; upstream recommends upgrading from at least v0.85.0. (github.com)
  • Rejects EC2/Lightsail service discovery in ScrapeConfig when Prometheus is >= 3.8.0. (github.com)

• CRD upgrade warning (operational breaking change): Helm upgrades commonly don’t upgrade CRDs automatically, which can cause failed upgrades / validation errors unless you update CRDs separately. (github.com)

Citations:

• 1: https://newreleases.io/project/github/prometheus-community/helm-charts/release/kube-prometheus-stack-81.0.0?utm_source=openai
• 2: https://github.com/prometheus-operator/prometheus-operator/releases
• 3: https://github.com/prometheus-operator/prometheus-operator/releases
• 4: [kube-prometheus-stack] New CRD subchart doesn't upgrade CRDs prometheus-community/helm-charts#3658

🌐 Web query:

kube-prometheus-stack v81 failurePolicy Prometheus Operator v0.88.0

💡 Result:

In kube-prometheus-stack v81.0.0 (which bumps Prometheus Operator to v0.88.0) the admission webhook behavior is controlled by:

prometheusOperator:
  admissionWebhooks:
    failurePolicy: Fail | Ignore | IgnoreOnInstallOnly

• v81.0.0 includes the operator bump to 0.88.0. [1]
• The chart supports Fail / Ignore / IgnoreOnInstallOnly for failurePolicy (with IgnoreOnInstallOnly meaning “Ignore on install, Fail afterwards”). [2]
• If you’re hitting install/upgrade errors like failed calling webhook ... x509: certificate signed by unknown authority / webhook not reachable, the common mitigation is setting failurePolicy: Ignore (or IgnoreOnInstallOnly) so the API server won’t block CR updates when the webhook is temporarily broken/unreachable. [3]

Also note: in this chart, if you explicitly set prometheusOperator.admissionWebhooks.failurePolicy, that value is used (even when the webhook patch job is enabled). [4]

Sources: [1] [2] [3] [4]

🌐 Web query:

forceDeployDatasources deprecated kube-prometheus-stack 81

💡 Result:

In the upstream prometheus-community/kube-prometheus-stack v81.x releases (e.g. 81.0.0 on Jan 16, 2026) there isn’t an announced removal of grafana.forceDeployDatasources; it’s still a supported value in the chart and is meant to “create datasource configmap even if grafana deployment has been disabled.” [1][2]

So if you’re seeing “deprecated” warnings, they’re most likely coming from a wrapper/consumer chart (or a values-schema/linter in your platform), not from kube-prometheus-stack itself.

What to do:

• If you disable Grafana in kube-prometheus-stack but still want the chart to render the Grafana datasource ConfigMap(s) for an external Grafana, keep using:
  • grafana.enabled: false
  • grafana.forceDeployDatasources: true (and similarly forceDeployDashboards if needed) [2]
• If you run Grafana via the subchart (grafana.enabled: true), you typically don’t need forceDeployDatasources (leave it false). [2]

Sources
[1] Release list showing kube-prometheus-stack 81.0.0/81.x (dates/versions) — releasealert.dev
[2] kube-prometheus-stack values.yaml changelog snippet documenting forceDeployDatasources purpose — baptiste.is-a.dev

🌐 Web query:

serviceMonitorSelectorNilUsesHelmValues deprecated removed v81

💡 Result:

In the prometheus-community/kube-prometheus-stack Helm chart, prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues (and the other *SelectorNilUsesHelmValues flags) were deprecated in the 62.x → 63.x upgrade, with a documented migration path. The chart maintainers recommend replacing them by explicitly setting the selector, and using matchLabels: null to force an “empty selector” behavior. [1]

What to do (migration)

If you previously had:

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false

Change to:

prometheus:
  prometheusSpec:
    serviceMonitorSelector:
      matchLabels: null

This same pattern applies to the related flags (podMonitorSelectorNilUsesHelmValues, probeSelectorNilUsesHelmValues, ruleSelectorNilUsesHelmValues, scrapeConfigSelectorNilUsesHelmValues, etc.). [1]

If you’re seeing failures on chart v81.x, it’s consistent with these deprecated flags no longer being accepted by the chart/templates you’re upgrading to—so removing them and switching to explicit selectors as above is the intended fix. [1]

Source
[1] kube-prometheus-stack upgrade notes (62.x → 63.x), deprecating *SelectorNilUsesHelmValues and the matchLabels: null replacement. (gist.github.com)

Citations:

• 1: https://gist.github.com/RobertKielty/a1d568a12b21008d2437521922d45ff3?utm_source=openai