Change naming of `Kind` to reflect apiserver reality - `GrafanaResourceDefinition`

[sdboyer]

Right now, the apiserver is or will shortly be using GrafanaResourceDefinition as the name that it presents to users for what we currently call "kinds" - specifically, the Core and Composable kinds. This is largely, though not entirely duplicative. That's gonna be confusing for folks!

That wording works over there, if only in explaining all the changes that are coming to Grafana devs. It's probably best to adapt here.

This also suggests a renaming needed for composable kinds, but that's probably OK. It'll also probably afford us an opportunity to revisit how we conceptually integrate the common schemas in all this. (And conceptual integration will help drive practical integration)

[sdboyer]

cc @ryantxu

[ryantxu]

what we currently call "kinds" - specifically, the Core and Composable kinds

Perhaps my understanding (and many others) of Core+Composable kinds is not accurate. IIUC:

• Core = kinds defined in core grafana. Does not care if it could/should be a k8s resource or not.
• Composable = kinds that live inside some other object -- eg specific panel or query options (heatmap vs sitewise)

We also have Custom (eg SLO -- things defined in the sdk) and also things defined in common that can be used across Core+composable kinds (eg TimeZone). Also kinds?

We currently do not have a distinction for things that will live as k8s resources -- and no way to easily distinguish that we are talking about the definition or the generic thing. So building on the standard k8s language, we can use:

• GrafanaResourceDefinition = the place we define and register schema+capabilities for items that will live in k8s (class in OO terms)
• GrafanaResource = a specific instance (object in OO terms)

[sdboyer]

Here's my way of thinking about it:

Core = kinds defined in core grafana. Does not care if it could/should be a k8s resource or not.

As i think of it, core kinds are just as bound to the k8s model as custom kinds now are, as of the agreement on a kind schema format (and moving all the core kinds down to have their bodies under the spec field)

Composable = kinds that live inside some other object -- eg specific panel or query options (heatmap vs sitewise)

pretty much, yeah. composable kinds are expected to come from plugins (or "extensions", to use the new general word?). The only thing missing in your note here is that every composable kind is constrained to follow exactly one of our schema interfaces

We also have Custom (eg SLO -- things defined in the sdk)

i think of these as essentially identical to core kinds - and for now, they just happen to be separated by a repo boundary, and perhaps some different requirements that core kinds have about how we make legacy systems map to them.

and also things defined in common that can be used across Core+composable kinds (eg TimeZone). Also kinds?

definitely not in current thinking. i struggled with this a lot in the original zero to maturity doc - this ended up in footnote 1. It's interesting to consider them as such in a k8s context, though. i don't think it's quite a fit, but i'm definitely undecided.

GrafanaResourceDefinition = the place we define and register schema+capabilities for items that will live in k8s (class in OO terms) GrafanaResource = a specific instance (object in OO terms)

:chef-kiss:

pretty much zactly what i wrote over here (though those docs need relocating)