-
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
Prometheus schematization #63878
Prometheus schematization #63878
Conversation
# Conflicts: # public/app/plugins/datasource/prometheus/types.ts
interval?: string | ||
intervalMs?: int64 |
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.
Are these set in the UI, or as part of the request? If we can not set them from the UI, lets keep them out of this schema.
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.
while i have a feeling we may find exceptions to this rule (such that we need to find a better rule), i think it's the right one at least for now
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 made the changes related to this. See: d4db739
{ | ||
common.DataQuery | ||
expr: string | ||
format?: 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.
What are the valid values? I think 'timeseries' and 'table', but would be nice to have that explicit :)
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.
Agree, if there's a set of acceptable values here, they should be explicitly declared.
Could make it a reference to another type, as with #QueryEditorMode
, if that type needs to be used elsewhere in TS
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 will check the possible values and introduce a change.
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.
See a0bd621
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 don't know the specifics of the prom datasource, but overall this looks pretty close! i think i'd just simplify a bit by removing pointers and some possibly-unnecessary fields from the schema as @ryantxu noted
{ | ||
common.DataQuery | ||
expr: string | ||
format?: 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.
Agree, if there's a set of acceptable values here, they should be explicitly declared.
Could make it a reference to another type, as with #QueryEditorMode
, if that type needs to be used elsewhere in TS
Co-authored-by: sam boyer <sdboyer@grafana.com>
| `format` | string | No | Possible values are: `time_series`, `table`, `heatmap`. | | ||
| `hide` | boolean | No | *(Inherited from [DataQuery](#dataquery))*<br/>true if query is disabled (ie should not be returned to the dashboard) | | ||
| `instant` | boolean | No | | | ||
| `key` | string | No | *(Inherited from [DataQuery](#dataquery))*<br/>Unique, guid like, string used in explore mode | |
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 was surprised to see "key" here... but then see that is not added in this PR
{ | ||
schemas: [ | ||
{ | ||
common.DataQuery |
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.
Any effort on comments here will be HUGELY helpful. The text+values here will drive all the docs and API generation, so if we can try to explain the parameters here (and agree/confirm they are accurate!) that would be awesome.
instant?: bool | ||
range?: bool |
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 both range and instant be true?
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.
they can't, and we can natively constrain them in CUE to indicate that invariant, but at the moment cuetsy evaluates the operation and converts the TS output to just false
- see grafana/cuetsy#75
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.
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.
oh! i totally misunderstood this on my first pass through it, then :)
"interval": "1s", | ||
"intervalMs": 1000, |
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.
Are these changes still necessary?
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.
Let me check them once more. Probably we won't need them anymore. Good catch.
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
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.
@itsmylife -- this looks like a great step forward. My only remaining comments would be to improve the comments so that a noice looking at the fields+comments could understand what they do.
But that can also evolve as we have more people look at and use this :)
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
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.
agreed with @ryantxu, i think this is good enough to go in - and be marked as experimental
. While it's absolutely true that the comments here are crucial for the as-code user use case, it takes a different mindset and knowledge base than just getting the types hooked up. It's OK to plan for a follow-up to improve them.
Thanks for all your work on this!
Co-authored-by: sam boyer <sdboyer@grafana.com>
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, thanks for all the hard work on this, I'm excited to have type synchronization across the stacks!
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! The comments make sense to me as well, good work!
* Schematize prometheus * revert changes * close response body * Update report.json * Update pkg/tsdb/prometheus/models/query.go Co-authored-by: sam boyer <sdboyer@grafana.com> * Use without pointers * remove unused * Specify query format * Rename * Clean up schema * Update public/app/plugins/datasource/prometheus/dataquery.cue Co-authored-by: Ryan McKinley <ryantxu@gmail.com> * Update pkg/tsdb/prometheus/models/query.go Co-authored-by: Ryan McKinley <ryantxu@gmail.com> * Clean up tests * Update public/app/plugins/datasource/prometheus/dataquery.cue Co-authored-by: sam boyer <sdboyer@grafana.com> * make gen-cue * Add comments * Make linter happy * Remove editormode override * Update --------- Co-authored-by: sam boyer <sdboyer@grafana.com> Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
What is this feature?
This is an example PR to illustrate schematizing the Prometheus datasource plugin. Probably It won't be merged.
The guidance https://docs.google.com/document/d/1RRPGeD7DQ7wot0Pwnc4UZolXrZYip0ViqOozl9zbBpE/edit#
Which issue(s) does this PR fix?:
Closes #63874
Special notes for your reviewer:
This PR is an up-to-date version of this PR. I closed that one because it was behind the main and getting hard to merge it because of the conflicts.