Non-blank value for UID required by Alerting Provisioning HTTP API for removing default contact point

[dugalp]

What happened:

Trying to provision contact points from source code configurations and cleaning up anything users may have created to ensure consistency from code to instance.

What you expected to happen:

We expect to be able to delete the default contact point after updating the root notification policy to a different contact point. However, the UID of the default contact point is blank, and the API needs a non-blank one.

How to reproduce it (as minimally and precisely as possible):

Step 1: Update the root notification policy to a non-default contact point.

Step 2: List the contact-points

curl https://admin:pwd@grafana-hostname.companyname.com/api/v1/provisioning/contact-points

    {
        "uid": "",
        "name": "email receiver",
        "type": "email",
        "settings": {
            "addresses": "\u003cexample@email.com\u003e"
        },
        "disableResolveMessage": false
    }

Step 3: remove the Contact point with a blank UID.

curl -X DELETE https://admin:pwd@grafana-hostname.companyname.com/api/v1/provisioning/contact-points/
{"message":"Not found"}

Note that the documentation mentioned a UID is required at the end of the URL, after "contact-points/{UID}" and we can't provide it as it's blank.

Anything else we need to know?:

The change request is here in the Pull Request: https://github.com/grafana/grafana/pull/66089

Environment: Not applicable

• Grafana version: Grafana enterprise 9.4.7
• Data source type & version: Not applicable
• OS Grafana is installed on: Not applicable
• User OS & Browser: Not applicable
• Grafana plugins: Not applicable
• Others: Not applicable

[mellieA]

I'm not able to reproduce this, can you share how you created the non-default contact that has a blank uid?

curl admin:admin@localhost:3000/api/v1/provisioning/contact-points | json_pp [ { "disableResolveMessage" : false, "name" : "new-email", "settings" : { "addresses" : "some_email@serverdomain.com", "singleEmail" : false }, "type" : "email", "uid" : "7V5MgSY4zz" },

[dugalp]

Hi @mellieA the default contact point is not created by me. It's probably created in code of Grafana. The request I'm making is here in the Pull Request which you will see on the left side of the code diff inside the pull request. It contains the code that may be creating a contact point with a blank ("") uid when installing and running for the first time from scratch: https://github.com/grafana/grafana/pull/66089

This means, it's not possible to automate the deletion with the Alerting Provisioning API to ensure everything is provisioned from code instead of relying on clickops to prepare a new instance that is ready to use and clean of defaults with a script. That's the goal, and perhaps not all users have the goal of eliminating clickops. But we do.

So if you could help suggest a better alternative to support full automation of provisioning an instance that requires deleting the default contact point without clickops, then we would be happy to potentially do that to clean up the default. Perhaps there is an API to update the UID without requiring one in the first place? Hmmm... Or perhaps the default contact point should have a UID.

Meanwhile, I have found a non-ideal workaround that does work (but leaves a bit to be desired) which is to leave the default contact point there and not delete it in a script. But that's not ideal. If I create a new contact point, then change the default one to that, and finally delete the default contact point created by Grafana with clickops -- then if I rebuild the Grafana instance, the default contact point created by Grafana and was deleted will re-appear as the default. So it's something Grafana does internally. As shown in the code, there isn't a UID for that default contact-point which makes deleting it via a script that uses the API difficult , and then requires clickops which is not ideal.

[nikos]

I am also experiencing this with a fresh Grafana installation (9.5.8) even if I do not modify anything (like described in the original bug report step 2). So it seems with the Alerting Provisioning API v1 impossible to change the default eamil receiver ("grafana-default-email") programmatically since the UID is an empty string.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last year. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!

[github-actions[bot]]

This issue has been automatically closed because it has not had any further activity in the last 30 days. Thank you for your contributions!

[m4rc77]

What happened to this bug and the related PR https://github.com/grafana/grafana/pull/66089? This issue is NOT yet solved with Grafana 11.2.2

It can easily be reproduced with the help of https://github.com/grafana/provisioning-alerting-examples/tree/main/config-files.

Just start the example with docker compose up an then navigate to http://localhost:3000/alerting/notifications?search=&tab=contact_points and click the "Export all" button. As a result you get:

contactPoints:
    - orgId: 1
      name: My Contact Email Point
      receivers:
        - uid: my_contact_email_point_uid
          type: email
          settings:
            addresses: your_email@company.org
            message: '{{ template "custom_email.message" .}}'
            singleEmail: false
            subject: '{{ template "custom_email.subject" .}}'
          disableResolveMessage: false
    - orgId: 1
      name: email receiver
      receivers:
        - uid: ""
          type: email
          settings:
            addresses: <example@email.com>
          disableResolveMessage: false

the receiver email receiver with the email example@email.com is created even though it is not defined in grafana/provisioning/alerting/alert_resources.yaml. And there is also no way to overwrite it as it has no UUID!

The provisioned contact points from the example are:

contactPoints:
    - orgId: 1
      name: My Contact Email Point
      receivers:
        - uid: my_contact_email_point_uid
          type: email
          settings:
            addresses: your_email@company.org
            message: '{{ template "custom_email.message" .}}'
            singleEmail: false
            subject: '{{ template "custom_email.subject" .}}'
          disableResolveMessage: false

In summary, there is currently (at least with 11.2.2) no way to get rid of the example@email.com contact point, when using alert provisioning without manual intervention. This is dangerous and could potentially leak sensitive internal operational information to whoever OWNs that email address!