[kube-prometheus-stack] inhibit InfoInhibitor alerts by default

[ANGkeith]

What this PR does / why we need it

Inhibit InfoInhibitor Alerts totally

Which issue this PR fixes

Special notes for your reviewer

Checklist

• DCO signed
• Chart Version bumped
• Title of the PR starts with chart name (e.g. [prometheus-couchdb-exporter])

[GMartinez-Sisti]

@ANGkeith are they not already inhibited?

Doesn't this

helm-charts/charts/kube-prometheus-stack/values.yaml

Lines 307 to 312 in ec52ff4

	- source_matchers:
	- 'alertname = InfoInhibitor'
	target_matchers:
	- 'severity = info'
	equal:
	- 'namespace'

Along with this

helm-charts/charts/kube-prometheus-stack/values.yaml

Lines 320 to 322 in ec52ff4

	- receiver: 'null'
	matchers:
	- alertname =~ "InfoInhibitor|Watchdog"

Achieves that?

[ANGkeith]

@GMartinez-Sisti

helm-charts/charts/kube-prometheus-stack/values.yaml

Lines 320 to 322 in ec52ff4

	- receiver: 'null'
	matchers:
	- alertname =~ "InfoInhibitor|Watchdog"

The above indeed will route the InfoInhibitor to the null receiver.

However, the problem is that, if any alertmanagerConfig is created,
eg.

apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: config-example
  labels:
    alertmanagerConfig: example
spec:
  route:
    groupBy: ["job"]
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 12h
    receiver: "webhook"
  receivers:
    - name: "webhook"
      webhookConfigs:
        - url: "http://example.com/"

the prometheus operator generates the following alertmanager config:

and the {alertname="InfoInhibitor", namespace="monitoring"} will end up getting routed to the receiver.

[GMartinez-Sisti]

Hi @ANGkeith, please fix the conflicts and see if you want to remove the route as #4081 suggested.

[ANGkeith]

@GMartinez-Sisti updated.

[GMartinez-Sisti]

The release failed because there was a 55.4.1 version already merged. @ANGkeith can you can send another PR with a bumped version pls?

Update: nevermind, something else was merged already.