-
Notifications
You must be signed in to change notification settings - Fork 57
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
Use tenant ID from incoming gRPC meta for instance caching #676
Conversation
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
Side note @bergquist, had you considered what (if anything) would change about how we handle metrics based on tenant info https://github.com/grafana/grafana-plugin-sdk-go/blob/main/backend/diagnostics_adapter.go#L25 |
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, amazing work 🚀!
Regarding the discussion around tenant id in context vs plugin context, I don't have any strong opinions, but I definitely agree about removing manual instance management from the public api in favor of automatic instance management.
Also worth mentioning that PluginContext
is a GRPC message, and adding tenant id over there would require changing the protobuf definition. Since we're not 100% sure yet how this deployment model will look like at the end, I personally think it's safer to have it in the grpc metadata for now, as that's much easier to remove/deprecate compared to protobuf.
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.
okay, let's go ahead with this if everyone agrees
What this PR does / why we need it:
Adds a new
tenant
package which is responsible for reading tenant information for each incoming plugin request. This information will be attached to the Go context, to be used as supplementary info for instance management caching.This approach is documented as option 2 in this doc.
Special notes for your reviewer:
The
InstanceManager
API requires a new context.Context argument for the relevant information to be propagated, which is the primary breaking change. This has an effect on core plugins and a number of community plugins.Breakdown of the changes:
A follow up will come to likely remove instance management (where possible) from the public API, in favour of the auto instance management functionality which is already used as part of the primary entrypoints for both apps and data sources