APIVersion: Add API Version to protobuf

[ryantxu]

In an effort to limit the number of supported backend versions, we will want to specify what apiVersion we want, and what we are running. This PR adds apiVersion to the protobuf and startup arguments so it can throw an error when there is a mismatch.

When versions are not set, there is no added verification

[wbrowne]

I think this makes sense 👍 But have you thought about how this relates to the plugin.json version, and how/where we might map them?

[ryantxu]

@wbrowne -- I updated this so we can now send the apiVersion when the plugin was saved. This can be something older than what people are currently running

[marefr]

Make sense to support passing the API version on each request, but would like some more context around ManagedOpts.APIVersion (see comment)

[marefr]

Why shouldn't the SDK support multi-version and/or why would you want to populate this? Hard to understand without seeing the full picture.

[ryantxu]

Good question -- I'll remove this config and make the api-management entirely up to the handler.

[wbrowne]

Also wondering - currently the runtime config param tells us what version of the API we want to run. But if we're loading a plugin as we traditionally do, we would want to know what it reports itself in order to validate, right?

[andresmgot]

FTR, I am taking a look at this and the discussion in grafana/grafana#76419. I'll try to gather the proposal and feedback and write a small design doc so we can agree. Hope that makes sense!

[ryantxu]

This change will propagate thought many things -- I'm not sure the best approach here, but these are a few exploration branches:
https://github.com/grafana/grafana/tree/datasource-apiversion
https://github.com/grafana/grafana/tree/plugin-apiserver

[wbrowne]

Nice! Just a few nits

[andresmgot]

I think a first step (before adding the API version to protobuf), would be to decide what would be the origin (source of truth) for this API version. Would that be the plugin.json or another schema somewhere?

[marefr]

LGTM

[marefr]

I think a first step (before adding the API version to protobuf), would be to decide what would be the origin (source of truth) for this API version. Would that be the plugin.json or another schema somewhere?

Don't think it's a blocker for merging this given it's not in use and currently we only have v0alpha1 for the foreseeable future so we can default to this to begin with if we want to start populating/forward this?

Feels like your question is related to how plugins can return openapi schemas per api version as well, i.e. resources. Something @ryantxu has been talking about earlier. So maybe this needs some additional discussions/design doc?

[ryantxu]

I think a first step (before adding the API version to protobuf), would be to decide what would be the origin (source of truth) for this API version. Would that be the plugin.json or another schema somewhere?

We can set the apiVersion when the request goes through an apisever with a version -- for now they are all hardcoded to "v0alpha1", so yes the next thing is to have a plugin somehow advertise which apiVerions it supports (and what is the preferred version). We need something to control:

plugin.json is the easiest, but may not be the best since we should also standardize on how plugins can define schemas, so maybe a new static file in a known place is a good path forward.

[andresmgot]

Don't think it's a blocker for merging this given it's not in use

Yes, that's my point. It will be dead code at the moment but 🤷

plugin.json is the easiest, but may not be the best since we should also standardize on how plugins can define schemas, so maybe a new static file in a known place is a good path forward

Yes, ideally a schema file with the query / settings definition would be the best but we kind of lost the progress there. We could temporarily use the plugin.json to specify that.

[andresmgot]

Code LGTM, we can merge even if it's not in use

[wbrowne]

🚀