Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • gitaly gitaly
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 658
    • Issues 658
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 49
    • Merge requests 49
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • gitalygitaly
  • Issues
  • #4459
Closed
Open
Issue created Sep 13, 2022 by James Fargher@proglottisMaintainer

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:

  1. How do we tell gitaly which agents have which features enabled
  2. 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 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.

Edited Sep 13, 2022 by 🤖 GitLab Bot 🤖
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking