-
|
I'm stumbling down the trail(s) you've blazed WRT to grafana dashboard schema/cue/polly, and would like to validate a few assertions. Specifically, I am trying to formalize some "standards" for Grafana Cloud integrations. Specifically around available, and preferred visualizations/panels. So..
I'm trying my best not to have to hand-curate a list of available, and preferred visualization types, to compare the existing mixins/dashboards against, but... It feels like I'm going to have to 🤔 |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
RE: 3, I found that the schema(s) do exist in public/app/plugins/panel/**/models.cue. Like this one for barchart. Same question remains for 2, related to each of those panel types. 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
Q&A is probably the wrong type of discussion for this, now that I'm adding more comments. At any rate.... It seems that the schema as-is won't solve my problem. The schema only adds rules which define the constraints for particular things. So for instance, when I add the barchart cue file, it only adds constrains that are specific to the barchart panel. Also, the panel schema definition itself only defines that the panel plugin type must be defined, but not which values are valid for that property. This all seems reasonable, and by design I suppose. Is it the intent that polly could produce a dashboard/alert/rule artifact which wouldn't pass validation when actually submitted to grafana/prometheus/cortex? |
Beta Was this translation helpful? Give feedback.
-
No, having this be impossible is pretty much the most foundational guarantee we're aiming for. (other q's here should be answered by my big reply below) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, there's a bunch of stuff that's half done. In general i haven't been doing a good job in making these temporary states clear by way of issues posted in polly and/or grafana, though i've been turning that around (at least with grafana) in the last week. May the trend continue :) To each item:
This - or at least, somewhere under
See the above issue. It's the intent that it be generated, but we've been sloppy in this first phase :)
Most complicated part, by far! i alluded to this in #31, but i'll expand specifically, here. The core dashboard schema - this - is defined without any explicit reference to the schema declared by plugins. This is a design necessity, because the possibility of third party plugins makes it impossible to statically enumerate, import, and compose in all possible plugins. Instead, we do that dynamically, at runtime. This gist is a dump of what that dynamically (in Go code) composed dashboard schema looks like, having pulled in all the schema currently defined in core plugins. (Note that a bunch of things are absent, because the default printing behavior omits optional fields, and we haven't yet written a custom one. That's a TODO, and once it's done, we'll add a The dynamic schema contains a huge disjunction (lines 62-409) which collectively comprises all the versions of all the core plugins. Look through, and you'll see each one, identified primarily by the The above is the normal, expected pattern. The dashboard schema directly contains The challenge in #31 is about replicating the Go logic that does this dynamic composition process, in CUE, so that we can produce the same logical schema. Eventually, i hope this kind of composition will be a standard pattern structured by the rules of scuemata itself, but we can hack it in for now. But you do highlight something important, here:
This is an important challenge - the non-enumerability of all plugins will affect Polly in the same way it affects Grafana core: we can't possibly write the Polly schema in a way that includes all third party plugins, wherever they may be defined. The only real choice we have here is to leave the schema open in such a way that, if the There are some steps we can take to tighten that up, but it's further down the road. For a while, the sanest path is going to be to only use core Grafana plugins when writing a pop. That's true even if the core plugin isn't currently in that gist, e.g. alertlist - it's pretty trivial to add a |
Beta Was this translation helpful? Give feedback.
Yeah, there's a bunch of stuff that's half done. In general i haven't been doing a good job in making these temporary states clear by way of issues posted in polly and/or grafana, though i've been turning that around (at least with grafana) in the last week. May the trend continue :)
To each item:
This - or at least, somewhere under
cue/- is the publicly importable place that the scuemata will live. The canonical version that's directly managed and updated by Grafana core devs will live somewhere else - more details in grafana/grafana#38033 - but for our purposes in polly, yeah, this is where the whole scuema…