Skip to content

Federated GitLab

Problem to solve

Teams want their own private instances of GitLab for various reasons, yet may need to interact with multiple private and public instances, including GitLab.com.

Further details

Make it easy to connect private instances of GitLab together, and to GitLab.com so that users can log into a single interface and see all of their projects. Note, there's another proposal to mirror information between instances, but this proposal is specifically about federating the data so it's presented in a single interface, but the single-source-of-truth remains on the distributed GitLab instances.

Specifically:

  1. A company could have multiple self-managed instances of GitLab, each with different users and different licenses
  2. An admin could connect the self-managed instances together, and to GitLab.com
  3. Users could log into a single private self-managed instance and see all projects they have access to across all self-managed instances, and the entirety of GitLab.com
  4. Caching may improve performance, but should not rely on a mirroring or synchronizing mechanism to see all the data consistently.

Other interesting benefits:

  1. Companies that want different licenses for different teams could segregate that team's projects into a higher-tier instance, while still allowing others to access the projects (with less features).
  2. There can be a deeper understanding of identities. e.g. when commenting on GitLab.com, we could understand what other instances that person has access to, and what licenses that person has access to, to better evaluate their comments.

Proposal

  1. Expose APIs so that all data can be searched and retrieved from an instance (with appropriate permissions)
  2. Leave rendering of the information to the local instance, possibly even having Javascript hit the remote server APIs directly
  3. Search should across all connected instances

Notes/questions

  1. There are so many details left unspecified here, but to start, if users are to fetch data from all instances, does that mean they need to have accounts on each instance? If so, that kind of blows the separate license benefit, and in fact makes it worse since the user count on each instance would be the sum of all users. But maybe that can be partially sidestepped by having a given user only have Guest access to an external Ultimate instance, for example. But perhaps more realistically, that Ultimate server would just be closed, and connected to a more open private instance for the rest of the company, so the federation isn't designed to be bidirectional, but allow the closed private server to be a single interface for users of it while providing access to the more open private server.

What does success look like, and how can we measure that?

(If no way to measure success, link to an issue that will implement a way to measure this)

Links / references

OSZAR »