Rule patching can use index to distinguish alert / record rules under the same name

[raptorsun]

• I added CHANGELOG entry for this change.
• No user facing changes, so no entry in CHANGELOG was needed.

The function patchOrExcludeRule uses an additional field "index" to distinguish different rules under the same name (alert/record field is considered as its name). Rules under the same group are ordered by alphabetic order in output.

For example, the following patch will add the field "patch:'A1' to the second rule of "alert:'A'".

local patchedRules = [
  {
    name: 'alertmanager.rules',
    rules: [
      {
        alert: 'A',
        index: 1,
        patch: 'A1',
        labels: {
          severity: 'warning',
        },
      },
      {
        alert: 'B',
        patch: 'B0',
        labels: {
          severity: 'warning',
        },
      },
      {
        alert: 'C',
        patch: 'C0',
        labels: {
          severity: 'warning',
        },
      },
      {
        alert: 'D',
        patch: 'D0',
        labels: {
          severity: 'warning',
        },
      },
    ],
  },
];

local rulesToPatch = [
  {
    name: 'alertmanager.rules',
    rules: [
      {
        alert: 'A',
        field: 'A0 rule',
        labels: {
          severity: 'warning',
        },
      },
      {
        alert: 'A',
        field: 'A1 rule',
        labels: {
          severity: 'warning',
        },
      },
      {
        alert: 'B',
        field: 'B0 rule',
        labels: {
          severity: 'warning',
        },
      },
    ],
  },
];

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: raptorsun

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [raptorsun]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[raptorsun]

Another PR with this rule patching function has been created in prometheus-operator/kube-prometheus repository, too.

[openshift-ci]

@raptorsun: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

@raptorsun: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Rerun command
ci/prow/e2e-aws-single-node	6a4cf14	link	/test e2e-aws-single-node
ci/prow/e2e-agnostic	6a4cf14	link	/test e2e-agnostic
ci/prow/e2e-agnostic-upgrade	6a4cf14	link	/test e2e-agnostic-upgrade
ci/prow/e2e-agnostic-operator	6a4cf14	link	/test e2e-agnostic-operator
ci/prow/go-fmt	6a4cf14	link	/test go-fmt

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[dgrisonnet]

Since we don't need this now in CMO, it would be better to add this functionality in kube-prometheus and bring it to CMO by reusing the upstream jsonnet script, wdyt?

[raptorsun]

Since we don't need this now in CMO, it would be better to add this functionality in kube-prometheus and bring it to CMO by reusing the upstream jsonnet script, wdyt?

Totally agree, I will close this PR, and use this PR in kube-prometheus to add this functionality instead.