Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alerting: Support recording rule struct in provisioning API #87849

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

rwwiv
Copy link
Contributor

@rwwiv rwwiv commented May 14, 2024

What is this feature?

Adds support for creating recording rules in the main API.

Recording rules have a new field, Record, and lack several of the other "statefulness" fields that only make sense for alerting rules.

Why do we need this feature?

Allows users to provision recording rules.

Which issue(s) does this PR fix?:

N/A

Special notes for your reviewer:

Please check that:

  • It works as expected from a user's perspective.
  • If this is a pre-GA feature, it is behind a feature toggle.
  • The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

@grafana-delivery-bot grafana-delivery-bot bot added this to the 11.1.x milestone May 14, 2024
@rwwiv rwwiv added area/alerting Grafana Alerting no-changelog Skip including change in changelog/release notes labels May 20, 2024
@rwwiv rwwiv marked this pull request as ready for review May 20, 2024 18:20
@rwwiv rwwiv requested review from a team as code owners May 20, 2024 18:20
@rwwiv rwwiv requested review from jtheory, JacobsonMT, yuri-tceretian, grobinson-grafana and inf0rmer and removed request for a team May 20, 2024 18:20
@rwwiv rwwiv force-pushed the rwwiv/recording-rule-provis-api branch from 685cfd5 to 5bb8638 Compare May 20, 2024 19:28
@@ -456,7 +456,17 @@ func NotificationSettingsFromAlertRuleNotificationSettings(ns *definitions.Alert
}
}

func ApiRecordFromModelRecord(r *models.Record) *definitions.Record {
func AlertRuleRecordFromRecord(r *definitions.Record) *models.Record {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we both wrote the same conversion func :D

I think this can be dropped (or can replace) ModelRecordFromApiRecord below

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just dropped this, prefer your naming scheme there 👍

@@ -477,6 +477,18 @@ type AlertRuleNotificationSettings struct {
MuteTimeIntervals []string `json:"mute_time_intervals,omitempty"`
}

// swagger:model
type Record struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my PR also introduced this type in this file - but your version is better because of the doc comments and examples. I think you'll need to delete mine? It's called the same thing.

"",
)
}

provenance := determineProvenance(c)
createdAlertRule, err := srv.alertRules.CreateAlertRule(c.Req.Context(), c.SignedInUser, upstreamModel, alerting_models.Provenance(provenance))
Copy link
Contributor

@alexweav alexweav May 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly I think we'll need to duplicate much of the validation code, inside the AlertRuleService too. The main API validation can't be reused by provisioning because of how that whole validation flow is architected (it mixes type conversions, that are specific to the main API, alongside validation - this is true for validation of all provisioning fields).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can ofc be saved for a future PR - but if we decide to do so, let's make sure we add a checkbox to the tasklist to remember it. We'll at least need to copy some validation logic, at most need to separate validation in a way that's reusable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/alerting Grafana Alerting area/backend area/frontend no-changelog Skip including change in changelog/release notes
Projects
Status: In review
Development

Successfully merging this pull request may close these issues.

None yet

2 participants