-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Plugins: Move alias support to plugin json (but still hardcoded) #75129
Conversation
@wbrowne -- I think this is safe to merge as is, and when (hopefully soon!) we have checks in gcom for alias the hardcoded errors can be removed 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.
Some initial review. If we add a new field to the plugin.json docs/sources/developers/plugins/plugin.schema.json and docs/sources/developers/plugins/metadata.md needs to be updated too.
That been said, I think that if we are adding support for that in plugins, we need to:
- Probably support more that one alias (for the third time a plugin ID changes)
- Documentation about how to add a new alias (e.g. adding a new ID to the hardcoded list)
plugin.Alias = "phlare" | ||
case "debug": // panel plugin used for testing | ||
plugin.Alias = "debugX" | ||
case "grafana-pyroscope-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.
Nit: can we move this switch-case to a map? I see this list growing and a switch-case is slower/more difficult to maintain.
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 whole section should be removed -- the only reason it exists is that we are waiting for parallel logic to exist in gcom. We want to be careful that anyone is not able to publish a plugin with an alias that we do not notice until it is too late :)
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.
Can't we just say - we implement logic in gcom and we make sure we dont publish any plugin or plugin updates that contain alias that we dont want and the ones we want can do it. Then we can (here in the core) trust that the ones that are published and have an alias in plugin.json are good to have an alias? Otherwise it will become hard to keep those hardcoded lists in sync.
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.
@tolzhabayev -- exactly. I have the check here so we can get everything working here and get it working in GCOM in parallel.
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.
GCOM Ticket https://github.com/grafana/grafana-com/issues/7467 to double check we have the same approach in mind
pkg/plugins/plugins.go
Outdated
if plugin.Alias == "" { | ||
return plugin, fmt.Errorf("expected alias to be set") | ||
} |
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 custom check seems to be not needed?
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 have no trouble removing it -- it just verifies that the alias was set the same from when we hardcoded it.
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.
yes, my concern is that people (us) start adding custom logic here to do more things (that's also why I like the idea of just having a map with the aliases)
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.
once we trust gcom... this whole section can be removed
"id": "annolist", | ||
"alias": "ryantxu-annolist-panel", |
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.
shouldn't this be:
"id": "grafana-annolist-panel",
"alias": "annolist",
?
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 do that -- but that is a different project :) The goal here is not to rename the ids, just setting alias in plugin.json rather than hardcoded
"id": "debug", | ||
"alias": "debugX", |
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 this plugin changing the id again to grafana-debug-panel
in the future so we may need to support a string array for alias(es)
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.
for this panel it should not matter -- this is an alpha panel just used for testing. The "debugX" is just a way to make sure that this same strategy works for our panels as it does for datasources :)
@andresmgot -- I get your point on docs... but IIUC, we want to be very careful about when this happens. It is not something we want to promote widely, but is a release. If we want to make it an array (even if it only supports a single item for now) that also seems reasonable, but previous discussions suggested it was not necessary. |
I am not sure then what we win with this? It's still needed to hardcode it and we would be adding a property to the plugin.json that it's not usable in the general case (and we don't want to expose it). |
pkg/plugins/plugindef/plugindef.cue
Outdated
@@ -18,6 +18,10 @@ schemas: [{ | |||
id: string & strings.MinRunes(1) | |||
id: =~"^([0-9a-z]+\\-([0-9a-z]+\\-)?(\(strings.Join([ for t in _types {t}], "|"))))|(alertGroups|alertlist|annolist|barchart|bargauge|candlestick|canvas|dashlist|debug|datagrid|gauge|geomap|gettingstarted|graph|heatmap|histogram|icon|live|logs|news|nodeGraph|piechart|pluginlist|stat|state-timeline|status-history|table|table-old|text|timeseries|trend|traces|welcome|xychart|alertmanager|cloudwatch|dashboard|elasticsearch|grafana|grafana-azure-monitor-datasource|graphite|influxdb|jaeger|loki|mixed|mssql|mysql|opentsdb|postgres|prometheus|stackdriver|tempo|testdata|zipkin|phlare|parca)$" | |||
|
|||
// An alias is useful when migrating from one plugin id to another (rebranding etc) | |||
// This should be used sparingly, and is currently only supported though a hardcoded checklist | |||
alias?: 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.
I also think it would make sense to just have this as a string[] just for sure. For example if we decide to merge 2 data sources into one. Or if we just make some mistake/typo at some point when renaming.
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.
updated so it is now aliasIds
🎉
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. Why not aliases
?
(Open the links below in a new tab to go to the correct steps)
|
@@ -58,7 +58,7 @@ export interface PluginMeta<T extends KeyValue = {}> { | |||
info: PluginMetaInfo; | |||
includes?: PluginInclude[]; | |||
state?: PluginState; | |||
alias?: string; | |||
aliasIds?: 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.
reports as a breaking change... but I think OK
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: the camel case for this would be aliasIDs
@@ -19,6 +19,7 @@ import ( | |||
"github.com/grafana/grafana/pkg/setting" | |||
"github.com/grafana/grafana/pkg/tsdb/grafanads" | |||
"github.com/grafana/grafana/pkg/util" | |||
"golang.org/x/exp/slices" |
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.
note this is standard in go 1.21
@andresmgot -- anything missing to merge this? OK to merge soon, then remove the explicit checks when we know HGAPI won't allow signing plugins with aliasIDs we do not expect? |
pkg/plugins/plugindef/plugindef.cue
Outdated
@@ -18,6 +18,10 @@ schemas: [{ | |||
id: string & strings.MinRunes(1) | |||
id: =~"^([0-9a-z]+\\-([0-9a-z]+\\-)?(\(strings.Join([ for t in _types {t}], "|"))))|(alertGroups|alertlist|annolist|barchart|bargauge|candlestick|canvas|dashlist|debug|datagrid|gauge|geomap|gettingstarted|graph|heatmap|histogram|icon|live|logs|news|nodeGraph|piechart|pluginlist|stat|state-timeline|status-history|table|table-old|text|timeseries|trend|traces|welcome|xychart|alertmanager|cloudwatch|dashboard|elasticsearch|grafana|grafana-azure-monitor-datasource|graphite|influxdb|jaeger|loki|mixed|mssql|mysql|opentsdb|postgres|prometheus|stackdriver|tempo|grafana-testdata-datasource|zipkin|phlare|parca)$" | |||
|
|||
// An alias is useful when migrating from one plugin id to another (rebranding etc) | |||
// This should be used sparingly, and is currently only supported though a hardcoded checklist | |||
alias?: [...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.
this needs to be aliasIDs
@@ -58,7 +58,7 @@ export interface PluginMeta<T extends KeyValue = {}> { | |||
info: PluginMetaInfo; | |||
includes?: PluginInclude[]; | |||
state?: PluginState; | |||
alias?: string; | |||
aliasIds?: 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.
nit: the camel case for this would be aliasIDs
I have some minor comments but yes, we can merge once that is addressed and the CI passes |
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.
LGTM, but naming it aliases
rather than aliasIDs
would simplify.
@@ -75,7 +73,7 @@ type JSONData struct { | |||
ID string `json:"id"` | |||
Type Type `json:"type"` | |||
Name string `json:"name"` | |||
Alias string `json:"alias,omitempty"` | |||
AliasIDs []string `json:"aliasIDs,omitempty"` |
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 json this should probably be camelCase, .e.g. aliasIds
. That's why I suggest to name it Aliases/aliases instead to simplify :)
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.
ID is uppercase so the camel case should be aliasIDs
?
I also first thought of aliases
but I think it's more descriptive to use aliasIDs
since it makes it clear that it's expecting plugin ID
s, not just any alias like a different name
.
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.
for sure we want ID in the name -- the confusion with name/type is already too much :) -- I am personally totally agnostic on the capitalization strategy. In go it is AliasIDs for sure, in json/ts... we use aliasIds elsewhere, but either is fine 🤷🏻
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.
feel free to merge with what you prefer
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 feel free
* main: (51 commits) Postgres: Make securejson password optional (#75801) Alerting: Manage remote Alertmanager silences (#75452) Replace use of `relref` shortcode with `docs/reference` so links work in Grafana Cloud (#75433) Add canonical for testing new canonical behavior in Grafana Cloud (#75745) InfluxDB SQL: Remove default limitation in the query (#75749) Publish documentation from the HEAD of the matching version branch on tag events (#73809) IDforwarding: forward signed id to plugins (#75651) Navtree: Rename page title from "Infrastructure" to "Integrations" (#75721) Changelog: Updated changelog for 9.5.12 (#75776) Chore: update latest.json to 10.1.4 (#75773) Changelog: Updated changelog for 10.1.4 (#75769) Changelog: Updated changelog for 10.0.8 (#75768) Tempo: TraceQL results as a spans list (#75660) Bug: Exclude 32-bit `arm` builds (#75448) Transformations: Fix inconsistent wording of transformation descriptions (#75746) i18n: dashboard import page (#75664) Fix issue-labeled GitHub Action (#75753) Schema: link table panel to the schema definitions (#75671) Plugins: Move alias support to plugin json (but still hardcoded) (#75129) Sandbox: allow access to window.grafanaBootData for plugins (#75522) ...
This is an update for #69874 and now targeting 10.2
This moves the alias support to plugin.json, but still throws an error if someone besides the hardcoded plugins try to set it.
Ideally we can update the hosted grafana plugin submission logic so it won't accept anything with alias unless we hardcode it there 🤷
but then release this with 10.2 -- that will mean that in the future there is a migration path for plugins like:
https://grafana.com/grafana/plugins/dlopes7-appdynamics-datasource/
https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app/
This also makes the alias an array, and matches the behavior in Registry.ts
https://github.com/grafana/grafana/blob/main/packages/grafana-data/src/utils/Registry.ts#L8