-
Notifications
You must be signed in to change notification settings - Fork 12.3k
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: Fix inconsistent AM raw config when applied via sync vs API #81655
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me! 👍
So this failed until a configuration was applied via the API? |
Yes, and then quickly started failing again once the periodic sync happened |
More so out of curiosity, how would I replicate that on main branch? |
|
AM config applied via API would use the PostableUserConfig as the AM raw config and also the hash used to decide when the AM config has changed. However, when applied via the periodic sync the PostableApiAlertingConfig would be used instead. This leads to two issues: - Inconsistent hash comparisons when modifying the AM causing redundant applies. - GetStatus assumed the raw config was PostableUserConfig causing the endpoint to return correctly after a new config is applied via API and then nothing once the periodic sync runs. Note: Technically, the upstream GrafanaAlertamanger GetStatus shouldn't be returning PostableUserConfig or PostableApiAlertingConfig, but instead GettableStatus. However, this issue required changes elsewhere and is out of scope.
e9e05ab
to
251c0e2
Compare
What is this feature?
AM config applied via API would use the
PostableUserConfig
as the AM raw config and also the hash used to decide when the AM config has changed. However, when applied via the periodic sync thePostableApiAlertingConfig
would be used instead.This changes makes all means of applying the AM config use
PostableApiAlertingConfig
.Why do we need this feature?
This issue causes:
GetStatus
(api/alertmanager/grafana/api/v2/status
) assumed the raw config wasPostableUserConfig
causing the endpoint to return correctly after a new config is applied via API and then nothing once the periodic sync runs.Who is this feature for?
UA users.
Special notes for your reviewer:
Technically, the upstream
GrafanaAlertamanger
GetStatus
shouldn't be returningPostableUserConfig
orPostableApiAlertingConfig
, but insteadGettableStatus
. However, this issue required changes elsewhere and is out of scope.