Propagate feature flag actors via Gitaly RPC metadata
Problem to solve
It would be useful if features could be turned on not only globally but by agent (user, group, project) so that new features can be tested with a subset of users without risking enabling it for everyone all at once.
There are two major issues to solve:
- How do we tell gitaly which agents have which features enabled
- How does gitaly know which features apply to which agents
How do we tell gitaly which agents have which features enabled
Typically right now a list of enabled feature flags is passed through to each RPC. This means we can detect and enable features as long as they are part of an RPC request. This means that feature flags do not really work for anything that is not triggered by a RPC, like background maintenance.
The overhead of this approach grows as more features are enabled at once, and so it probably wont scale to also have a list of every enabled agent for every feature passed with every RPC. It seems likely that such a list of enabled features with agents would have to be stored in praefect/gitaly.
There is some work to better pass features from praefect to gitaly !4584 (closed) but this will still require passing enabled agent/feature data over every RPC. So with the current praefect/gitaly setup it may require storing feature/agent data in all services involved, each praefect and each gitaly.
How does gitaly know which features apply to which agents
Some RPCs are designed around a user taking an action, typically named User*
.
All repositories managed by gitlab-rails use the SetFullPath
RPC to set their project path. This string could be used to match specific projects and a prefix match could be used to match groups, but there is currently no way to query for a repository associated with a specific "full path".
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.