feat: Add feature flags for read path #4211
Conversation
api/querier/v1/querier.proto
Outdated
|
|
||
| // GetFeatureFlags returns the enabled backend feature flags for the current tenant | ||
| rpc GetFeatureFlags(types.v1.GetFeatureFlagsRequest) returns (types.v1.GetFeatureFlagsResponse) {} |
There was a problem hiding this comment.
I think we should have a dedicated service.
It's more convenient for both the client and the server. Otherwise, we would need to add the handler to every service, along with its implementation (so we also need to support this in the client). I've already counted 6 implementations, and we might also need handlers for VCS, ad-hoc, tenant settings, OTLP, and other services we may add later.
The API method feels rather out of place here – the querier service should be responsible for queries only.
As for scope (not sure if we really need it), it could just be a parameter in the request.
pkg/featureflags/featureflags.go
Outdated
| if !flag.Parameters.Enabled { | ||
| continue | ||
| } |
There was a problem hiding this comment.
I'm not sure I understand the purpose of the Enabled flag. If we filter out disabled features, we probably don't need the Enabled attribute (at least at the API level)
simonswine
force-pushed
the
20250529_add-feature-flags
branch
from
f322d28 to
9f45d97
Compare
simonswine
force-pushed
the
20250529_add-feature-flags
branch
from
9f45d97 to
9e62963
Compare
Add metrics
simonswine
force-pushed
the
20250529_add-feature-flags
branch
from
9e62963 to
5aaa906
Compare
This implements #4095
Contrary to the initial plan, it provides a CapabilityService with FeatureFlag API targeting the read path only. It is exposed by QueryFrontends/Queriers.
The state of those feature flags is directly derived from the config and can't be changed during runtime. Those feature flags are exposed via metrics.