-
Notifications
You must be signed in to change notification settings - Fork 11.8k
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: Update API to use folders' full paths #81214
Conversation
c566960
to
da85196
Compare
6d9b358
to
c222d70
Compare
c222d70
to
a148072
Compare
use fake user with enough permissions to fetch all folders
3040f9b
to
5bf3482
Compare
Error: Contact #proj-ephemeral-hg-instances if it is not a compile error handling pull request comment event: calling gcom to upsert instance: creating instance: unexpected response status: status=409 responseBody={ |
/deploy-to-hg --enterprise-ref yuri-tceretian/fullpaths-folder |
|
|
return folder, nil | ||
if len(f) == 0 { | ||
return nil, dashboards.ErrFolderAccessDenied | ||
} |
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.
This is to replicate FolderService.Get
behavior. @papagian, I wonder if you can fix Get to provide full path too.
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.
sure, I'll do but I would suggest not to block the current work (merge this one and address it in a follow up)
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.
@yuri-tceretian the FolderService.Get()
change: #81972
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.
Looking very good, a couple question comments that are quite minor. I will defer the folderimpl
changes to @papagian
@@ -705,29 +704,3 @@ func GroupByAlertRuleGroupKey(rules []*AlertRule) map[AlertRuleGroupKey]RulesGro | |||
} | |||
return result | |||
} | |||
|
|||
// GetNamespaceKey concatenates two strings with / as separator. If the latter string contains '/' it gets escaped with \/ | |||
func GetNamespaceKey(parentUID, title string) string { |
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.
Small reminder to merge the Enterprise change (consuming this function) before or at the same time as this PR 😄
pkg/services/ngalert/api/api.go
Outdated
@@ -128,6 +128,7 @@ func (api *API) RegisterAPIEndpoints(m *metrics.API) { | |||
featureManager: api.FeatureManager, | |||
appUrl: api.AppUrl, | |||
tracer: api.Tracer, | |||
rulesStore: api.RuleStore, |
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.
Nit: RuleStore is a pretty large interface, and we seem to only use it to actually query for folders, not even rules directly. Rather than adding fairly big dependency here, would it be worth declaring a minimal interface containing just GetNamespaceByUID
and whatever else is needed?
} | ||
|
||
// RouteTestGrafanaRuleConfig returns a list of potential alerts for a given rule configuration. This is intended to be | ||
// as true as possible to what would be generated by the ruler except that the resulting alerts are not filtered to | ||
// only Resolved / Firing and ready to send. | ||
func (srv TestingApiSrv) RouteTestGrafanaRuleConfig(c *contextmodel.ReqContext, body apimodels.PostableExtendedRuleNodeExtended) response.Response { | ||
folder, err := srv.rulesStore.GetNamespaceByUID(c.Req.Context(), body.NamespaceUID, c.OrgID, c.SignedInUser) | ||
if err != nil { | ||
return toNamespaceErrorResponse(dashboards.ErrFolderAccessDenied) |
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.
In the previous version, we purely passed along the UID without validating it.
I think there are contexts where this endpoint may be hit without a valid folder supplied (i.e. you try to test your query and have not yet selected a folder in the UI, the folder selector being below the query).
Does this break such cases, by attempting to look up the folder and failing the test if it's not yet selected? Or, is there a spot later in the flow that does this lookup anyway? We could consider filling the folder with something arbitrary and allowing the test to proceed.
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.
Unfortunately, this becomes mandatory in this API. Otherwise, we risk providing incorrect routing information. Previously we took the folder title from the request and it was enough but UI cannot provide full path in the folder title anymore. So, I had to update it. Anyway, as long as user has access to the rule it has access to the folder it contains.
OrgID: f.OrgId, | ||
UID: f.Uid, | ||
for orgID, uids := range uids { | ||
schedulerUser := accesscontrol.BackgroundUser("grafana_scheduler", orgID, org.RoleAdmin, |
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.
Could we extract schedulerUserFor
in schedule.go
to some shared location and call it from here? And add the folder permissions to it?
That way we don't have an inconsistency if the fake user ever changes, and we have a list of all combined permissions for the rule evaluation in one place.
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.
The problem here is that this is supposed to be a multi-org user (it requires per -org permissions) we can extract it to a function but it won't make any difference because we won't be able to pass it around in scheduler. Another problem is where to put it... perhaps in store
or in models
package but neither of them seem to be good.
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.
I see. I wonder if we could change UX so user is not guided into the path? Put folder selector next to name selector, above the query or something? @gillesdemey
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.
Clicked the wrong comment box...that was meant for the one about testing API
#81214 (comment)
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
however I observe some no rule groups found errors but I assume that these are attempts to fetch rule from the different data sources
return folder, nil | ||
if len(f) == 0 { | ||
return nil, dashboards.ErrFolderAccessDenied | ||
} |
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.
sure, I'll do but I would suggest not to block the current work (merge this one and address it in a follow up)
those are for Lotex APIs. I did not touch them in this PR |
/deploy-to-hg --enterprise-ref yuri-tceretian/fullpaths-folder |
/deploy-to-hg --enterprise-ref yuri-tceretian/fullpaths-folder |
|
|
* update GetUserVisibleNamespaces to use FolderSeriver * update GetNamespaceByUID to use FolderService.GetFolders * update GetAlertRulesForScheduling to use FolderService.GetFolders * Update API and GetAlertRulesForScheduling to use the folder's full path * get full path of folder in RouteTestGrafanaRuleConfig * fix escaping of titles for MySQL
What is this feature?
This PR changes Alerting API and Scheduler to refer to a folder using its full path.
This will have the following effect:
grafana_folder
.Why do we need this feature?
This is needed to properly support nested folders and relaxed constraints that allow folder title to be unique only among folders that share the same parent.
Who is this feature for?
Users of nested folders
Which issue(s) does this PR fix?:
Fixes #80324
Special notes for your reviewer:
Please check that:
Release notice breaking change
The following breaking change occurs only when feature flag
nestedFolders
is enabled.If the folder title contains the symbol
/
(forward-slash) the notifications created from the rules that are placed in that folder will contain an escape sequence for that symbol in the labelgrafana_folder
.For example, the folder title is
Grafana / Folder
. Currently the labelgrafana_folder
will contain the title as it is. If PR is merged - the label value will beGrafana \/ Folder
.This can break notifications if notification policies have matches that match that label and folder.