Use Explore's Prometheus editor in dashboard panel edit

[davkal]

• adds PromQueryField to query editor partial
• query is being pushed down for the initial value, and changes coming from the editor bubble up and override the panel target

[torkelo]

You cannot import stuff from the app from grafana ui

[torkelo]

Don’t want plugins to have access to the panel model , why do query editors need this ? They could need panel plugin meta info like supported data formats , but want to shield plugins from the actual panel model as this has some legacy things like event emitter and persisted state that we will likely want to change in the future without affecting plugins

[CLAassistant]

All committers have signed the CLA.

[torkelo]

Is this still WIP? what is the state? let me know if this can be tested and & merged. Or is it waiting for getting the latest query response added to the QueryEditorProps interface?

[davkal]

Basic functionality is done. Needs tests. Hope to finish off next week.

[davkal]

This is ready for an initial review.

Given that the editor component no longer has access to the panel controller, we're missing two things for the external link generation: 1) dynamic step interval from the panel, 2) template variables updates

The dynamic step interval is probably less important than the template variables. It's going to be very frustrating when someone exits to Prometheus and starts debugging, only to find out that they are operating on a different cluster/datacenter/instance. Any idea on how we can force a render of the link when the variables update? @torkelo

[torkelo]

should this not also trigger a run query so you see the effect?

[torkelo]

why caps?

[torkelo]

Did a quick poc for adding queryResponse & queryError to react query editor props:
#16233

[davkal]

@torkelo any guidance on how panel editors should react to a user changing template variables? This is needed for the external link creation.
Since the editor has no access to the dashboard, they can't subscribe to 'template-variable-value-updated' their events.

[torkelo]

We need pass variables in as props, but with the PR I linked to above you will also get a new query response as queries are executed in variable change, but to show variables in auto complete suggestions we need to pass variables in as props as well

[davkal]

@torkelo Great, I can trigger a render then. Will wait for #16233

[torkelo]

That PR (queryRespone & queryError) is now available in master, merged via this other PR from ryan #16306

But added refId filtering to both queryError and queryResponse, so we need to add refId to errors and series responses in the Prometheus response handling.

[torkelo]

Now that we have queryResponse & queryError in the QueryEditorProps would be interesting as next steps to review how we can align & remove the Prometheus/loki specific from the Explore query interfaces:

export interface ExploreQueryFieldProps<DSType extends DataSourceApi, TQuery extends DataQuery> {
  datasource: DSType;
  query: TQuery;
  error?: string | JSX.Element;
  hint?: QueryHint;
  history: any[];
  onExecuteQuery?: () => void;
  onQueryChange?: (value: TQuery) => void;
  onExecuteHint?: (action: QueryFixAction) => void;
}

Would like to remove hint & onExecuteHint as they seem internal details that can be handled inside the QueryEditor. For example datasource.getQueryHints could be an internal Prometheus specific function that the QueryEditor calls, does not need to be a public function on DataSourceApi.

[davkal]

LGTM. Thanks for taking this on @hugohaggmark

IMO this can go in as is. Someone other than me needs to give a review (I opened the PR.)

The one piece of functionality we're missing over the existing editor is start/end awareness of metadata queries (when requesting labels, start and end from the visible range should be sent as well). We should add this in a follow-up PR.

[hugohaggmark]

LGTM!