-
Notifications
You must be signed in to change notification settings - Fork 11.6k
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
Annotations: Support filtering the target panels #66325
Conversation
annotations?: { | ||
|
||
// TODO -- should not be a public interface on its own, but required for Veneer | ||
#AnnotationContainer: { |
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.
@sdboyer -- thoughts on how to best handle this? a nested type AnnotationQuery.target
needs a Veneer... but that sets off a cascade of all the parents needing one also
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 cascade being this change, for example? https://github.com/grafana/grafana/pull/66325/files#diff-932ad9420b4f3774837637528ee5bfe0ac3581cca3c5fdad61beb944aedbc45aR33
nope, no current or planned way around that. Would require the sort of generics support in cuetsy that i haven't yet seen what i consider to be a feasible proposal
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.
not a huge deal -- just checking that I am not missing anything.
|
||
// unless datasources have migrated to the target+mapping, | ||
// thhey just spread their query into the base object :( | ||
... |
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.
@sdboyer is this the accepted choice for "or anything else" here?
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.
Yep, if we have to accept unknown fields being spilled in here as valid, this is how to mark it.
It may be possible to not do this if it's possible for us to know at schema-time whether the datasource plugin in question has done the "target+mapping migration" you mention in the comment (idk what that is). That would be analogous to how if we encounter a panel that's from a plugin for which we have no composable kind, we let the options
field be anything/unrestricted
#AnnotationTarget: { | ||
limit: int64 | ||
// Only required/valid for the grafana datasource... |
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.
we could potentially model this special case directly, here in schema - but it would be preferable to refactor the grafana datasource to avoid such hacks
const panels: Array<SelectableValue<number>> = useMemo( | ||
() => | ||
dashboard?.panels | ||
.map((panel) => ({ | ||
value: panel.id, | ||
label: panel.title ?? `Panel ${panel.id}`, | ||
description: panel.description, | ||
imgUrl: config.panels[panel.type].info.logos.small, | ||
})) | ||
.sort((a, b) => (a.label > b.label ? 1 : -1)) ?? [], | ||
[dashboard] | ||
); |
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.
a way to move this to DashboardModel and maybe we can reuse this in the Shared dashboard query editor?
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.
It looks a bit different, hm..
…#66671) remove localStorage mock which doesn't work in node v18.16.0
Co-authored-by: Gilles De Mey <gilles.de.mey@gmail.com>
* clean up navmodel interface * remove concept of sections from NavModel interface * clean up applinks
…#66281) * TimePicker: Fixes issues with "Recently used absolute ranges" section Squashed commit of the following: commit 99d5076 Author: Joao Silva <joao.silva@grafana.com> Date: Tue Apr 11 14:06:27 2023 +0100 user essentials mob! :trident: lastFile:public/app/core/components/TimePicker/TimePickerWithHistory.tsx commit cad0201 Author: eledobleefe <laura.fernandez@grafana.com> Date: Tue Apr 11 11:44:34 2023 +0200 user essentials mob! :trident: lastFile:public/app/core/components/TimePicker/TimePickerWithHistory.tsx Co-authored-by: eledobleefe <laura.fernandez@grafana.com> * TimePicker: Add correct date format * Add convertRawToRange tests * Rename test variables * RTL tests * Proper RTL tests * Apply suggestions from code review Co-authored-by: Joao Silva <100691367+JoaoSilvaGrafana@users.noreply.github.com> * Remove commented line * Fix linting --------- Co-authored-by: eledobleefe <laura.fernandez@grafana.com> Co-authored-by: Tobias Skarhed <tobias.skarhed@gmail.com> Co-authored-by: Tobias Skarhed <1438972+tskarhed@users.noreply.github.com>
Squashed commit of the following: commit 421bd0b Author: Joao Silva <joao.silva@grafana.com> Date: Tue Apr 4 10:48:04 2023 +0100 user essentials mob! :trident: lastFile:public/app/plugins/panel/annolist/AnnoListPanel.tsx commit 862846a Author: joshhunt <josh@trtr.co> Date: Tue Apr 4 10:35:35 2023 +0100 user essentials mob! :trident: commit 4ddc7fe Author: Tobias Skarhed <tobias.skarhed@gmail.com> Date: Tue Apr 4 11:20:08 2023 +0200 mob next [ci-skip] [ci skip] [skip ci] lastFile:public/app/plugins/panel/annolist/AnnoListPanel.tsx Co-authored-by: joshhunt <josh@trtr.co> Co-authored-by: Tobias Skarhed <tobias.skarhed@gmail.com>
* try a different way to run integration tests * fix formatting * clean test cache again * use previous command * playing around with random commands * dont run tests in parallel yet * use parallel option instead of gomaxprocs * use same package set for redis/memcached; use p=1
This commit adds support for limits and filters to the Prometheus Rules API. Limits: It adds a number of limits to the Grafana flavour of the Prometheus Rules API: - `limit` limits the maximum number of Rule Groups returned - `limit_rules` limits the maximum number of rules per Rule Group - `limit_alerts` limits the maximum number of alerts per rule It sorts Rule Groups and rules within Rule Groups such that data in the response is stable across requests. It also returns summaries (totals) for all Rule Groups, individual Rule Groups and rules. Filters: Alerts can be filtered by state with the `state` query string. An example of an HTTP request asking for just firing alerts might be `/api/prometheus/grafana/api/v1/rules?state=alerting`. A request can filter by two or more states by adding additional `state` query strings to the URL. For example `?state=alerting&state=normal`. Like the alert list panel, the `firing`, `pending` and `normal` state are first compared against the state of each alert rule. All other states are ignored. If the alert rule matches then its alert instances are filtered against states once more. Alerts can also be filtered by labels using the `matcher` query string. Like `state`, multiple matchers can be provided by adding additional `matcher` query strings to the URL. The match expression should be parsed using existing regular expression and sent to the API as URL-encoded JSON in the format: { "name": "test", "value": "value1", "isRegex": false, "isEqual": true } The `isRegex` and `isEqual` options work as follows: | IsEqual | IsRegex | Operator | | ------- | -------- | -------- | | true | false | = | | true | true | =~ | | false | true | !~ | | false | false | != |
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; a few nits but overall this is looking great!
public/app/features/dashboard/components/AnnotationSettings/AnnotationSettingsEdit.tsx
Outdated
Show resolved
Hide resolved
public/app/features/dashboard/components/AnnotationSettings/AnnotationSettingsEdit.tsx
Show resolved
Hide resolved
public/app/features/dashboard/components/AnnotationSettings/AnnotationSettingsEdit.tsx
Outdated
Show resolved
Hide resolved
…6702) Co-authored-by: Leon Sorokin <leeoniya@gmail.com>
Co-authored-by: Leon Sorokin <leeoniya@gmail.com>
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
Fixes #717
This PR updates the annotations system to support filtering which panels should get the data:
From the annotations editor you can now select where to show the annotations:
Then annotations are only sent to the selected panels:
TODO: